Opened 8 years ago

Closed 8 years ago

#37522 closed defect (fixed)

doxygen: UsingTheRightCompiler

Reported by: raimue (Rainer Müller) Owned by: cssdev
Priority: Normal Milestone:
Component: ports Version: 2.1.2
Keywords: haspatch Cc: ryandesign (Ryan Schmidt), maehne (Torsten Maehne), cooljeanius (Eric Gallager), mamoll (Mark Moll)
Port: doxygen

Description

Here is a patch to fix the invocation of the compiler in the libmd5 subdirectory, see UsingTheRightCompiler.

This patch also removes the obsolete lion.patch, that was still commented out in the Portfile and a small correction to the patch arguments by passing -p1 in pre_args, not post_args (previous command was patch -p0 -p1).

Please apply this patch with svn patch, as it does not contain a full diff for the deleted file.

Attachments (5)

doxygen-compiler.diff (1.4 KB) - added by raimue (Rainer Müller) 8 years ago.
main.log (178.5 KB) - added by g5pw (Aljaž Srebrnič) 8 years ago.
Build failure on ML with +wizard
main.2.log (32.9 KB) - added by ryandesign (Ryan Schmidt) 8 years ago.
good.log (72.7 KB) - added by ryandesign (Ryan Schmidt) 8 years ago.
bad.log (29.1 KB) - added by ryandesign (Ryan Schmidt) 8 years ago.

Download all attachments as: .zip

Change History (15)

Changed 8 years ago by raimue (Rainer Müller)

Attachment: doxygen-compiler.diff added

comment:1 Changed 8 years ago by ryandesign (Ryan Schmidt)

Cc: ryandesign@… added

Cc Me!

comment:2 Changed 8 years ago by cssdev

Status: newassigned

comment:3 Changed 8 years ago by maehne (Torsten Maehne)

Cc: Torsten.Maehne@… added

Cc Me!

comment:4 Changed 8 years ago by g5pw (Aljaž Srebrnič)

It still fails on my machine, ML with the +wizard variant, due to a stray "-arch i386". Attaching logfile.

Changed 8 years ago by g5pw (Aljaž Srebrnič)

Attachment: main.log added

Build failure on ML with +wizard

comment:5 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Resolution: fixed
Status: assignedclosed

Changed 8 years ago by ryandesign (Ryan Schmidt)

Attachment: main.2.log added

comment:6 in reply to:  5 Changed 8 years ago by ryandesign (Ryan Schmidt)

Resolution: fixed
Status: closedreopened

Replying to g5pw@…:

It still fails on my machine, ML with the +wizard variant, due to a stray "-arch i386". Attaching logfile.

That is a different problem: #37546

Replying to jeremyhu@…:

r102643

That does not fix it for me.

comment:7 Changed 8 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

comment:8 Changed 8 years ago by ryandesign (Ryan Schmidt)

Resolution: fixed
Status: reopenedclosed

After some investigation it turns out to be a parallel build issue. I guess libmd5 is depended on in multiple places, and in at least one place, the correct compiler name and flags are not passed along.

Fixed in r103086 by turning parallel build off.

comment:9 Changed 8 years ago by ryandesign (Ryan Schmidt)

Resolution: fixed
Status: closedreopened

Not fixed. It still randomly uses cc instead of ${configure.cc}. Attaching both a "good" and a "bad" log. In the "good" case, Makefile.libmd5 actually gets replaced by the following command:

env TMAKEPATH=/opt/local/var/macports/build/_Users_rschmidt_macports_dports_textproc_doxygen/doxygen/work/doxygen-1.8.3/tmake/lib/macosx-c++ /opt/local/bin/perl /opt/local/var/macports/build/_Users_rschmidt_macports_dports_textproc_doxygen/doxygen/work/doxygen-1.8.3/tmake/bin/tmake libmd5.pro >Makefile.libmd5

Changed 8 years ago by ryandesign (Ryan Schmidt)

Attachment: good.log added

Changed 8 years ago by ryandesign (Ryan Schmidt)

Attachment: bad.log added

comment:10 Changed 8 years ago by ryandesign (Ryan Schmidt)

Cc: mmoll@… added
Resolution: fixed
Status: reopenedclosed

The problem was caused by r101062 (committed less than a day before this ticket was filed) which added a reinplace on three tmake.conf files, Makefile.libmd5, and Makefile.libdoxycfg. But Makefile.libmd5 and Makefile.libdoxycfg are supposed to be regenerated by tmake, using the tmake.conf. The problem must be occurring when the tmake.conf file that is actually being used is modified in the same second as the Makefiles are modified, resulting in the build process believing that the Makefiles are already up to date and do not need to be regenerated.

The solution is to reinplace only the tmake.conf file; then the Makefiles will be regenerated from it. And there's no need to reinplace three different tmake.conf files; the port will only use one of them, as defined by the port's ${tmake_conf} variable.

Fixed in r103089.

Note: See TracTickets for help on using tickets.