[MacPorts] #48231: doxygen @1.8.9.1: update to 1.8.10
#48231: doxygen @1.8.9.1: update to 1.8.10 ----------------------------+-------------------------------- Reporter: mschamschula@… | Owner: macports-tickets@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: haspatch | Port: doxygen ----------------------------+-------------------------------- doxygen has been updated to version 1.8.10. Instead of tmake the new version uses cmake. The means a number of adjustments. My attached patches have only been tested with the default variant. I tried to build the docs variant, and found that the build stage attempted to copy files into /opt/local. This should only occur in the destroot phase. -- Ticket URL: <https://trac.macports.org/ticket/48231> MacPorts <https://www.macports.org/> Ports system for OS X
#48231: doxygen @1.8.9.1: update to 1.8.10 -----------------------------+---------------------- Reporter: mschamschula@… | Owner: css@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Resolution: | Keywords: haspatch Port: doxygen | -----------------------------+---------------------- Changes (by ryandesign@…): * cc: css@… (removed) * cc: ryandesign@… (added) * owner: macports-tickets@… => css@… Comment: There are numerous issues to be resolved here before this could be committed, but a big one is the libiconv patch you attached to prevent the use of MacPorts libiconv. That won't work, because the patch includes details specific to your MacPorts installation, including the MacPorts prefix, the location of Xcode, the build architecture, the C++ std library, the deployment target, the location of your ports tree, maybe more. We want to build with MacPorts libiconv. The missing symbols error you saw when building with MacPorts libiconv should be reported to the developers of doxygen so they can fix it. The missing symbols error often indicates that the headers of MacPorts libiconv are being used while the library of OS X libiconv is being used, or vice versa. Looks like there are cmake variables that one should be able to set to tell the build system which libiconv to use (`ICONV_INCLUDE_DIR:PATH` and `ICONV_LIBRARY:FILEPATH`) but setting these has no effect. I suspect this is another symptom of the same problem. -- Ticket URL: <https://trac.macports.org/ticket/48231#comment:1> MacPorts <https://www.macports.org/> Ports system for OS X
#48231: doxygen @1.8.9.1: update to 1.8.10 -----------------------------+---------------------- Reporter: mschamschula@… | Owner: css@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Resolution: | Keywords: haspatch Port: doxygen | -----------------------------+---------------------- Comment (by mschamschula@…): The updated Portfile (and accompanying patch file) fixes the libiconv issue: we now use MacPorts iconv. -- Ticket URL: <https://trac.macports.org/ticket/48231#comment:2> MacPorts <https://www.macports.org/> Ports system for OS X
#48231: doxygen @1.8.9.1: update to 1.8.10 -----------------------------+---------------------- Reporter: mschamschula@… | Owner: css@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Resolution: | Keywords: haspatch Port: doxygen | -----------------------------+---------------------- Comment (by mschamschula@…): The latest update fixes the docs and wizard variants. -- Ticket URL: <https://trac.macports.org/ticket/48231#comment:3> MacPorts <https://www.macports.org/> Ports system for OS X
#48231: doxygen @1.8.9.1: update to 1.8.10 -----------------------------+---------------------- Reporter: mschamschula@… | Owner: css@… Type: update | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Resolution: fixed | Keywords: haspatch Port: doxygen | -----------------------------+---------------------- Changes (by cal@…): * status: new => closed * resolution: => fixed Comment: Committed in r143539 with the following changes: - patch doc/CMakeLists.txt to install manpages in share/man - add explicit cmake.out_of_source no, because out of source build fails - backport compatibility fixes for flex 2.6, see #49881 -- Ticket URL: <https://trac.macports.org/ticket/48231#comment:4> MacPorts <https://www.macports.org/> Ports system for OS X
participants (1)
-
MacPorts