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 317773 - Dynamic .spec File Improvement
Dynamic .spec File Improvement
Status: RESOLVED FIXED
Product: doxygen
Classification: Other
Component: build
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: Dimitri van Heesch
Dimitri van Heesch
Depends on: 320786
Blocks: 314832 318542 320815 498049
 
 
Reported: 2005-10-02 22:40 UTC by Kevin McBride
Modified: 2012-11-18 11:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed .spec file (2.55 KB, patch)
2005-10-02 22:41 UTC, Kevin McBride
needs-work Details | Review
Proposed changes to configure, Makefile.in, and packages directory. This is a bzipped-tarball. (9.12 KB, application/x-bzip2)
2005-10-22 05:57 UTC, Kevin McBride
  Details
An updated configure script (16.63 KB, patch)
2005-10-24 22:36 UTC, Kevin McBride
none Details | Review
doxygen-try4.tar.bz2 - Another Improvement (132.50 KB, application/x-compressed-tar)
2005-11-06 04:45 UTC, Kevin McBride
  Details
doxygen-try5.tar.bz2 - Fixes for QT checking (5.98 KB, application/x-compressed-tar)
2005-11-06 06:26 UTC, Kevin McBride
  Details
Documentation Install Fix (783 bytes, patch)
2005-11-06 19:29 UTC, Kevin McBride
none Details | Review
Added .pdf inclusion to the .spec files. This is a bzipped tarball. (2.10 KB, application/x-compressed-tar)
2005-11-10 06:59 UTC, Kevin McBride
  Details
Complete patch, altogether, as try7.tar.bz2. This is a bzipped tarball. (17.23 KB, application/x-compressed-tar)
2005-11-10 07:49 UTC, Kevin McBride
  Details
Turns on the compilation of debuginfo package (72 bytes, patch)
2005-11-12 10:18 UTC, Kevin McBride
rejected Details | Review
Timestamps on .t Files updated, removed debuginfo exclusion. This is a bzipped-tarball. (17.20 KB, application/x-compressed-tar)
2005-11-12 17:48 UTC, Kevin McBride
  Details
RPM-Only patch as requested by Dimitri. This is a bzipped-tarball. (7.01 KB, application/x-compressed-tar)
2005-11-18 03:06 UTC, Kevin McBride
  Details

Description Kevin McBride 2005-10-02 22:40:02 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.
Comment 1 Kevin McBride 2005-10-02 22:41:01 UTC
Created attachment 52950 [details] [review]
Proposed .spec file
Comment 2 Kevin McBride 2005-10-02 22:45:55 UTC
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.  :)
Comment 3 Kevin McBride 2005-10-07 23:12:40 UTC
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.
Comment 4 Dimitri van Heesch 2005-10-09 09:52:02 UTC
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?
Comment 5 Kevin McBride 2005-10-09 17:17:19 UTC
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.
Comment 6 Kevin McBride 2005-10-09 17:20:57 UTC
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
Comment 7 Kevin McBride 2005-10-10 22:56:24 UTC
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.
Comment 8 Kevin McBride 2005-10-22 05:57:48 UTC
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.
Comment 9 Kevin McBride 2005-10-22 05:58:46 UTC
Re-opening bug for another sign-off attempt.
Comment 10 Sebastian 2005-10-23 09:31:47 UTC
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. 
Comment 11 Kevin McBride 2005-10-23 14:41:21 UTC
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.
Comment 12 Kevin McBride 2005-10-23 15:03:24 UTC
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.
Comment 13 Dimitri van Heesch 2005-10-24 17:52:33 UTC
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).

Comment 14 Kevin McBride 2005-10-24 22:32:01 UTC
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?
Comment 15 Kevin McBride 2005-10-24 22:34:55 UTC
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.
Comment 16 Kevin McBride 2005-10-24 22:36:49 UTC
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.
Comment 17 Kevin McBride 2005-10-24 22:47:23 UTC
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.
Comment 18 Kevin McBride 2005-10-26 06:18:10 UTC
Changing summary of this bug report because the .spec file has been found usable
on many distros.
Comment 19 Dimitri van Heesch 2005-10-26 20:00:14 UTC
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?
Comment 20 Kevin McBride 2005-10-29 21:36:33 UTC
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.
Comment 21 Kevin McBride 2005-11-05 16:57:31 UTC
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.
Comment 22 Kevin McBride 2005-11-06 04:45:52 UTC
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.  :)
Comment 23 Kevin McBride 2005-11-06 05:16:06 UTC
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.
Comment 24 Kevin McBride 2005-11-06 06:26:24 UTC
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.
Comment 25 Kevin McBride 2005-11-06 19:29:40 UTC
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.
Comment 26 Kevin McBride 2005-11-10 06:59:18 UTC
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.
Comment 27 Kevin McBride 2005-11-10 07:49:19 UTC
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.
Comment 28 Kevin McBride 2005-11-12 10:18:21 UTC
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.
Comment 29 Kevin McBride 2005-11-12 12:08:00 UTC
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.
Comment 30 Kevin McBride 2005-11-12 17:48:08 UTC
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.
Comment 31 Kevin McBride 2005-11-12 19:07:18 UTC
I have rebuilt my i686 and i386 RPMs successfully with my latest attatchment.
Comment 32 Kevin McBride 2005-11-12 19:22:32 UTC
Bug report filed in Red Hat's bugzilla for review.  URL is:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173033
Comment 33 Dimitri van Heesch 2005-11-13 13:18:27 UTC
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.



Comment 34 Kevin McBride 2005-11-13 15:55:35 UTC
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.
Comment 35 Kevin McBride 2005-11-13 16:03:27 UTC
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.
Comment 36 Dimitri van Heesch 2005-11-14 13:35:26 UTC
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?
Comment 37 Kevin McBride 2005-11-18 02:54:35 UTC
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.
Comment 38 Kevin McBride 2005-11-18 03:06:56 UTC
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.
Comment 39 Kevin McBride 2005-11-18 03:13:24 UTC
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.
Comment 40 Kevin McBride 2005-11-18 16:02:35 UTC
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

Comment 41 Dimitri van Heesch 2005-11-19 13:20:08 UTC
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.
Comment 42 Kevin McBride 2005-11-19 16:02:09 UTC
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.
Comment 43 Kevin McBride 2005-11-28 00:08:36 UTC
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.