On Tue, 24 May 2005, IOhannes m zmoelnig wrote:
� wrote:
FYI, I have rewritten the Gem build system for my debian packaging, a patch against 0.90 is attached. I haven't checked if it works with the CVS version, but in general it should be a lot cleaner than the
well, it did not apply too cleanly against the CVS....
anyhow, after i managed to patch the tree, i have some questions:
- i get an error with PKG_CHECK_MODULE which i don't like very much (but
it seems to work)
pkg-config is a way how many libraries tell the user how they are compiled. If its good or bad, I don't know, but in general it works.
- are options generally a bad style ("--without-ftgl") or are they
missing just because you didn't care ? should we re-do them ? has the way they have been used been dirty (i am not much of a autoconf-hacker) ??
I think that the system should give reasonable default values whenever possible. That is, if there is FTGL installed on the system it should use FTGL. But its not bad style, it changes from case to case. So if there is a real need for being able to adapt which libraries are used, then a --enable --disable makes sense.
- what about the "strange hacks" ? i can compile Gem against standard
debian-ffmpeg for quite some time (against the shared libs!), why do we need such weird tests ?
Yes, best would be to get rid of the strange hacks section, this is why I called it this way. The adoption of ffmpeg into Debian make the ffmpeg part useless, so we can throw it out.
- most important: is there a way to use "-config"-scripts with autoconf
? e.g. avifile comes with an "avifile-config"-script which gives you the needed flags for compiler & linker: ffmpeg comes with one too; i do think we should use these scripts (as they probably know best what is needed)
Yes, thats what the PKG_CHECK_MODULE should do. If it doesn't than i would have to figure out how it is done correctly.
- shouldn't the script fail when not finding hard dependencies (e.g.
openGL) ?
Yes, maybe. I left it out to keep the script clean. Maybe we put that part at the end, where the system prints the configuration, telling the user what was going wrong and give a summary of what was missing. This way he can install all the dependenies in one go and doesn't have to go through and install/configure/fail cycle.
- is it good to calculate the compiled files on the fly ? i mean, this
is certainly ok for a packager who assumes, that all the files compile fine; but during development process it is often convenient if i can in/exclude files from being build. (ok that is a rather simple thing to fix)
maybe its not good, I don't know. I have taken this choice mainly for simplicity. Maybe detecting files that are not compilable is a good thing too. You can still remove the offending files if you need to do a fast compilation, but it should default to compile all if possible.
- is there any good reason to not use libdv ? (i guess this is because
of the missing dv1394.h-file in both libdv4-dev and gem-0.90.0 ???
Can't remember, I am going to check. In general the configure.ac should be considered as a proposal, not a solution. I would have to go through it and adapt it to CVS probably (or any other developer can do that too). I just sent it as an option as a fresh starting point, rather than trying to fix the old system.
apart from that, it is surely cleaner (at least: shorter) than the old script. and it compiled fine
Thats good, would be happy if you take it into consideration to adopt it. I don't have any problem if you don't, it was just that it was lying around already.
Cheers, Guenter
mfg.a.dr IOhannes