Opened 11 years ago
Closed 11 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 Carsten 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)
Change History (15)
Changed 11 years ago by raimue (Rainer Müller)
| Attachment: | doxygen-compiler.diff added |
|---|
comment:1 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
| Cc: | ryandesign@… added |
|---|
comment:2 Changed 11 years ago by cssdev
| Status: | new → assigned |
|---|
comment:4 Changed 11 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 11 years ago by g5pw (Aljaž Srebrnič)
Build failure on ML with +wizard
comment:5 follow-up: 6 Changed 11 years ago by jeremyhu (Jeremy Huddleston Sequoia)
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
| Attachment: | main.2.log added |
|---|
comment:6 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
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@…:
That does not fix it for me.
comment:8 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
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 11 years ago by ryandesign (Ryan Carsten Schmidt)
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
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 11 years ago by ryandesign (Ryan Carsten Schmidt)
Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
comment:10 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
| Cc: | mmoll@… added |
|---|---|
| Resolution: | → fixed |
| Status: | reopened → closed |
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.
Cc Me!