After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 597518 - Makefile for Docsets does not honor DESTDIR
Makefile for Docsets does not honor DESTDIR
Status: RESOLVED FIXED
Product: doxygen
Classification: Other
Component: general
1.6.1
Other Mac OS
: Normal enhancement
: ---
Assigned To: Dimitri van Heesch
Dimitri van Heesch
Depends on:
Blocks:
 
 
Reported: 2009-10-06 07:53 UTC by Jens Miltner
Modified: 2009-12-30 13:38 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Jens Miltner 2009-10-06 07:53:13 UTC 
When creating Xcode Docsets with doxygen (which, BTW, is a very nice addition), the generated Makefile will always install into ~/Library/Developer/Shared/Documentation/DocSets.

We have an Xcode project that builds documentation for our frameworks and I would like to have the documentation not being installed in ~/Library/Developer/Shared/Documentation/DocSets, but rather in a location defined by me (in this case the project's output location). I therefore tried to run make with DESTDIR=$ouputDir, but found that the Makefile that doxygen generates will ignore the DESTDIR environment variable and use the hardcoded installation path instead.

It would be very nice if the generated Makefile would honor the DESTDIR variable, like most other standard Makefiles do for installation.
Comment 1 Dimitri van Heesch 2009-10-25 08:46:41 UTC 
This is already possible if you use DOCSET_INSTALL instead of DESTDIR, but it makes sense to use DESTDIR indeed.
Comment 2 Dimitri van Heesch 2009-12-30 13:38:49 UTC 
This bug was previously marked ASSIGNED, which means it should be fixed in
doxygen version 1.6.2. Please verify if this is indeed the case and reopen the
bug if you think it is not fixed (include any additional information that you
think can be relevant).