GNOME Bugzilla – Bug 317773
Dynamic .spec File Improvement
Last modified: 2012-11-18 11:12:55 UTC
Distribution/Version: Fedora Core When the release of doxygen-1.4.4 became official, I created a new doxygen.spec file, to be used for the Fedora Core and Red Hat distros of Linux. As of doxygen-1.4.4-5, I have not recieved any bug reports regarding the new spec file. Attatched to this bug report is a .spec file to be reviewed and included in the next official release of doxygen. It will generate three binary RPMs; one for the manual, one for the doxywizard, and one for the doxygen program itself. The reason why I chose doxywizard to be put in a seperate RPM is to allow doxygen to be installed in cases where the X Window system was not installed. In addition, the revision number in my .spec file should be incremented on every release, and reset to "1" when the major and/or minor version numbers change. The reason for this is to identify what CVS-only release the generated RPMs reflect. The RPMs on my web site utilize this procedure.
Created attachment 52950 [details] [review] Proposed .spec file
I do not mind of maintaining the proposed .spec file within the CVS repository. So, if you want me to maintain the .spec file directly within the doxygen CVS, let me know in your reply. :)
Follow up: I am curious to know if any one has reviewed over the .spec file for a decision on whether or not to include it in future official distributions.
I'm currently looking at it. I can't really test or verify if all paths are ok, as I do not use Fedora myself, but I don't mind including it anyway. There is one issue though. I do not want to update the file manually each time I make a new release, so things like: %define version 1.4.4 %define revision 5 have to be adjusted automatically. The version of CVS release is something like 1.4.5-20051009, so how can this be translated automatically? Is it ok to use %define version 1.4.5 %define revision 20051009 instead? And how does it then look for the "official" 1.4.6 release?
I have managed to get GNU autotools to work with spec.in's, but I am not familiar with tmake, so is there any way we can get the configure script to produce the .spec file from a spec.in? If so, then the version in my proposed .spec file could be automatically incremented.
Also, I just noticed that we are currently providing a .spec file in doxygen's source code that is already out-of-date. Summary: A documentation system for C/C++. Name: doxygen Version: 1.4.2 Release: 1
Marking my .spec file as "needs work" - I just found a few minor areas that need to be fixed. In addition, I need to try to get the .spec file to dynamically generate itself from tmake.
Created attachment 53753 [details] Proposed changes to configure, Makefile.in, and packages directory. This is a bzipped-tarball. The attatched tarball should solve two bugs in one stone: - The RPM improvement, plus making the RPM .spec file dynamic. User will need to run configure first, then su --command="make rpm" to generate rpms. Even better, if --with-doxywizard is not specified, rpmbuild will not build the doxywizard package. - Allowing doxygen to be built from a different directly, as noted in the "blocked" bug. Before commiting the contents of the tarball to CVS, two files need to be removed from doxygen, and then put into the attic. - packages/rpm/build.sh This script has been obsoleted by the new "make rpm" command. - VERSION The configure script will now generate this file. There are variable on the top of the configure script that affect the generation of this file. Auto-generation of the VERSION file was necessary to make the .spec files dynamic. I hope this is the end of the hard work I have put into this bug.
Re-opening bug for another sign-off attempt.
on suse 9.3 with the kde 3.4.3 rpms installed the doxygen-doxywizard*rpm refuses to install: rpm -Uhv doxygen-doxywizard-1.4.5-20051010.i586.rpm error: Failed dependencies: qt >= 3.3 is needed by doxygen-doxywizard-1.4.5-20051010 ops:/usr/src/packages/RPMS/i586 # rpm -qa | grep qt qt3-3.3.4-29 changing the the Requires: qt3 in the doxygen.specs will make it working, but don't know whether it may break sth. somewhere else.
My Qt is: 3.3.3 and my .spec files do work fine on a Fedora Core 3. What's the version of your rpm and rpmbuild, Sebastian? If rpm version is less than RPM version 4.3.2, you may want to try upgrading your rpm utility.
quote: in the doxygen.specs will make it working, but don't know whether it may break sth. somewhere else. Nope, they shouldn't break. Even if upgrading your rpm utility doesn't help, then we know there's only a slight change that needs to be made for the package to work in SuSE. I guess Dimitri will have to document the qt3 checking in the rpm building section before he makes another official release of doxygen. also, binary rpms were meant to be distro-dependent, so some small editing of the .spec files may be necessary to get a working rpm to build. There's no way I can avoid the end user's need to edit the .spec files 100%, but I have done my best to reduce the need to edit them as much as possible.
Hi Kevin, I noticed you always copy all sources to the destination directory even if it is the currently directory. Couldn't that be optimized to only do it if needed? Should be even nicer if only the objects and executables are put in the destination directory. Did you try that? (otherwise I may do an attempt myself).
quote: "Hi Kevin, I noticed you always copy all sources to the destination directory even if it is the currently directory. Couldn't that be optimized to only do it if needed?" Yes, it is possible. I have attatched an updated configure script for you to view. quote: "Should be even nicer if only the objects and executables are put in the destination directory. Did you try that?" Yes, I tried. Unfourtunately, troll make would not allow me to put only the objects and executables in the destination directory. The only workaround to this situation is to cat a variable to the beginning of every Makefile.in. However, doing so would add the variable before the GPL info. Is it okay to have a patch that does such a thing?
actually, we can't fool troll make using cat. Something else will have to be used, but I am not sure what else would work.
Created attachment 53856 [details] [review] An updated configure script This is an updated configure script that has the ability to avoid copying source files when building directly in the source tree.
I just noticed that we can use symbolic links and hard links. Configure can check to see that such a linkage is possible within the system, and if possible, make the required links for the sources. If any one has any ideas about how to solve the "only the objects and executables are put in the destination directory" issue, please post a comment to this bug.
Changing summary of this bug report because the .spec file has been found usable on many distros.
Thanks for the config file update. To my second question you said: "Yes, I tried. Unfourtunately, troll make would not allow me to put only the objects and executables in the destination directory. The only workaround to this situation is to cat a variable to the beginning of every Makefile.in. However, doing so would add the variable before the GPL info. Is it okay to have a patch that does such a thing?" It's ok, but not the nicest thing. Maybe a better approach is to put a clear & unique marker like INSTALLDIR or so in the Makefile.in and use sed -e "s/INSTALLDIR/something/" to replace it by the right variable at configure time. Would that do the trick?
I have taken a further look at a generated Makefile.qtools. There are three markers possible: ../objects/ - apparently, for storing objects temporairily. ../bin/ - for storing generated executables. ../lib/ - for storing statically linkable libraries. both of these markers should be feedable through a string replacement utility so that the user can choose which directory the makefiles should temporairily store the objects and executables. I'll give it a try.
I think I have come up with another solution. I have inserted the following into Makefile.in of qtools: tmake: $(OURENV) $(PERL) ../$(TMAKE) qtools.pro >Makefile.qtools.tmp $(ECHO) "DOXYGEN_SRC_DIR = ../$(DOXYGEN_SRC_DIR)/qtools" > Makefile.qtools.tmp2 $(CAT) Makefile.qtools.tmp2 Makefile.qtools.tmp > Makefile.qtools $(RM) Makefile.qtools.* Makefile.qtools: $(MAKE) tmake and in qtools.pro.in, a sample source file is found as: SOURCES = $(DOXYGEN_SRC_DIR)/qbuffer.cpp \ I will post in a few hours whether or not this method works on everything, not just qtools. It's the only method that seems to work at the moment.
Created attachment 54377 [details] doxygen-try4.tar.bz2 - Another Improvement Here is try 4 of the patch. The tarball contains only the changes I have made for the enhancement to be acceptable for inclusion. There are two types of files I could not avoid copying: .t - tmake couldn't take in a directory argument from a .pro file. .h (doxywizard only) - tmake wouldn't generate moc's unless the header files are in the directory containing the generated Makefiles. Every other source file is read from the source directory, and a 'make distclean' will remove the files described above that have to be copied. The two major pros of this patch are, of course, configuring from a directory different from the source root and an improved .spec file. :)
The 'try 4' patch can only be applied to a CVS snapshot of doxygen 1.4.5-20051024, either from the appropriate tarball on http://www.planetsaphire.com/doxygen or directly from CVS. Applying the patch to other versions will definitely cause undefined results. Also, the changes I have made may have shown a compilation problem caused by the GNU Compiler. Currently, gcc-4.0.1 reproduces bug # 320786. I have a patch on that bug report that you can apply over src/util.cpp of doxygen to work around the bug, should you run into it after applying the 'try 4' patch.
Created attachment 54380 [details] doxygen-try5.tar.bz2 - Fixes for QT checking While building some test RPMs, there were some unexpected flaws found in the QT checking. This tarball has the fixes to the bug for doxygen 1.4.5-20051024. Whether or not it was my changes that exposed the flaws remains unknown, but if you're getting QT linkage errors after applying the try4 patch, try applying the try5 patch.
Created attachment 54393 [details] [review] Documentation Install Fix I recently discovered a problem with installing doxygen outside the source directory. This patch will fix a minor issue that keeps info pages from installing. Also, in order to get the pdf to generate, you'll need to edit something in the configure script: FIND: DOXYGEN = $(DOXYGEN_SRC_DIR) REPLACE: DOXYGEN = .. This will get the pdf to generate in the source directory. Generating pdf's outside of the source directory is too much work with troll make, so I will not add support for generating pdfs of doxygen outside the source directory. I hope Dimitri will include the three patches I have.
Created attachment 54564 [details] Added .pdf inclusion to the .spec files. This is a bzipped tarball. I have added .pdf inclusion to the .spec files, as shown in the newly attatched tarball. The most recent three patches (54337, 54380, and 54393) must be applied before the .spec files will have any chance of working reliably. The generated .pdf's will be added to the manual package.
Created attachment 54565 [details] Complete patch, altogether, as try7.tar.bz2. This is a bzipped tarball. I have made this tarball, excluding all the source files, so that the patches can be safely applied to 1.4.5-20051109.
Created attachment 54666 [details] [review] Turns on the compilation of debuginfo package Fedora Core wants the debug info package compilation to be turned on before they will accept my changes. This patch will turn it on for doxygen.spec.in, and is turned on similarly for the doxygen-nodoxywizard.spec.in. I will also rebuild my i386 RPMs to test the change.
rpmbuild refuses to build doxygen unless the debuginfo package is defined to NIL (no debuginfo package) or not referenced at all, even in comments. Therefore, the line shown to be replaced in my attatchment must be removed entirely.
Created attachment 54674 [details] Timestamps on .t Files updated, removed debuginfo exclusion. This is a bzipped-tarball. I had to update the timestamps on all the .t files in the doxygen source code to get GNU make satisfied that all the .t files were up-to-date when compiling inside the source tree. I also removed the debuginfo exclusion from both .spec.in's. debuginfo packages are a requirement for consideration of new packages (even updates) to Fedora Core. Both updates will be found in the try8 tarball.
I have rebuilt my i686 and i386 RPMs successfully with my latest attatchment.
Bug report filed in Red Hat's bugzilla for review. URL is: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173033
I'm afraid there is still a serious problem with dependency generation. If you look at Makefile.libdoxygen you'll see rules like: ../objects/translator.o: $(DOXYGEN_SRC_DIR)/translator.cpp $(CXX) -c $(CXXFLAGS) $(INCPATH) -o ../objects/translator.o $(DOXYGEN_SRC_DIR)/translator.cpp whereas in the old situation, it looked like: ../objects/language.o: language.cpp \ message.h \ language.h \ translator.h \ qtbc.h \ classdef.h \ entry.h \ memberlist.h \ memberdef.h \ definition.h \ sortdict.h \ util.h \ config.h \ lang_cfg.h \ translator_en.h \ translator_adapter.h \ version.h \ translator_nl.h \ translator_se.h \ translator_cz.h \ translator_fr.h \ translator_id.h \ translator_it.h \ translator_de.h \ translator_jp.h \ translator_je.h \ translator_es.h \ translator_ru.h \ translator_hr.h \ translator_pl.h \ translator_pt.h \ translator_hu.h \ translator_ke.h \ translator_kr.h \ translator_ro.h \ translator_si.h \ translator_cn.h \ translator_tw.h \ translator_no.h \ translator_br.h \ translator_dk.h \ translator_sk.h \ translator_ua.h \ translator_gr.h \ translator_sr.h \ translator_ca.h \ translator_lt.h \ translator_za.h $(CXX) -c $(CXXFLAGS) $(INCPATH) -o ../objects/language.o language.cpp In other words all dependency information is lost! Apparently tmake doesn't know where to look for header files if there is a $(DOXYGEN_SRC_DIR) before the source file name. I'm not sure yet how one could fix this. Maybe you can have a look. For now I'm going to have to revert to the old situation, as developing without proper dependencies is not workable.
You're not going to at least include the spec file? I am sure there's plenty of users who can utilize it. Sure, I will look at why the dependency information on the makefiles got lost, but not including at least the spec file improvement is going to make things much worse. By the way, GNU autotools can solve more than this, I will post more reasons to that bug report.
Addition to comment 34: "Sure, I will look at why the dependency information on the makefiles got lost, but not including at least the spec file improvement is going to make things much worse." I meant that the new spec files and the "make rpm" command, even without the other Makefile improvements, are supposed to make it easier for those who generate RPMs. Without committing at least the new spec files and necessary changes to the /Makefile.in and configure script, everyone will have to edit the existing .spec file, or create a new one.
I have no problem including the spec file + other spec related changes. Would it be possible for you to make a patch containing only those changes so I don't forget something?
I am now doing a test build of the .spec patch. An attatchment will be posted if the test build is successful. Also, do we really need to have a "configure.bin" file? I don't see that it's necessary for Fedora Core, yet the "make dist" command looks for a "configure.bin" file in the source tree, and the configure script doesn't generate it (even unmodified). Therefore, my attatchment will have an empty configure.bin file.
Created attachment 54899 [details] RPM-Only patch as requested by Dimitri. This is a bzipped-tarball. Please make sure the packages/rpm directly is clean before applying this patch so that the obsoleted .spec file and the build.sh script will never be referenced again. Also, this patch makes three commands available: "make rpm" - Makes a source rpm and a few binary rpms. "make rpmsrc" - Makes a source rpm only. "make rpmbinary" - Makes binary rpms only.
Dimitri, if you approve this patch, you may also want to add a few lines to the changelog of the .spec files: %changelog * Thu Nov 18 2005 Dimitri van Heesch <dimitri@stack.nl> 1.4.6 - This .spec file has been added to the official releases of doxygen. You can, of course, put whatever comment you want in the changelog, so you don't have to comment with the exact wording that I have illustrated above.
I forgot to insert VERSION file generation into the newest tarball. The following code can be inserted anywhere into the configure script, but must be inserted after the doxygen_version* definitions: # # Make VERSION file # echo " Created VERSION file." # Output should be something like 1.4.5-20051010 if test "$doxygen_version_mmn" = NO; then echo "$doxygen_version_major.$doxygen_version_minor.$doxygen_version_revision" > VERSION else echo "$doxygen_version_major.$doxygen_version_minor.$doxygen_version_revision-$doxygen_version_mmn" > VERSION fi
Hi Kevin, w.r.t. the configure.bin in comment #37: make packaging script bundles it with the binary distribution (after being renamed to configure). The reason: if you want to install just the binaries, there is no need for doing things that are needed for building doxygen from source (like checking for perl or generating lang_cfg.h). So we should either add this as a "mode" to the one and only configure script or use two configure scripts. Ideas are welcomed.
Adding "help wanted" keyword so that other people will know that we need input for this enhancement. I will take a look at the configure.bin and see what we can come up with that's acceptable for committing to the CVS.
I am closing this bug as "Resolved - Fixed" and removing the HELPWANTED keyword. The rpm patch has been applied to 1.4.5-20051127, and testing reveals that the patch works without any problems. The configure.bin improvement is going to be on a new bug that I will add shortly. Dimitri, make sure you at least make an empty configure.bin using the `touch' command before you make an official release of 1.4.6. If you don't, those who use the `make rpm' command will end up with a "can't find configure.bin" error, before rpmbuild even runs.