wow, for 10 seconds my MUA showed very weird asteriskes and symbols. it has serious problems with guessing the correct encoding of your emails.... (but it was fun to look at)
� wrote:
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.
it seems to be fine, but it will only work if a package comes with an appropriate .pc-file. (.pc like "pkgconfig")
some packages do (on debian at least) some dont (like ffmpeg); but it seems that far more packages come with a .pc-file than with a "*-config" helperscript.
pkgconfig is also cross-platform, so in theory it should work well on osX; the only package that would be of interest here is probably ftgl: is there an ftgl.pc file somewhere ?; it seems like the one in the debian-distro is provided by the package-maintainer.
- 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.
as a developer i prefer the option to explicitly disable/enable things at my will (so i can more easily reproduce the behaviour on machines that lack a certain library)
i have no idea how you do as a package-maintainer: i thought being able to explicitely specify how the package should be build should ease your task.
e.g. you have commented out the support of libdv in the configure.in script, in order to disable it. wouldn't it be far simpler to give a command line flag to configure that it should not use libdv because gem-0.90.0 and libdv4 don't like each other ?
i don't know the new debian build system, but i remember well that the old build scripts were usually filled with configure-options.
and of course it should be possible to package Gem without the need to patch the source-code.
- 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
how should mutual exclusions be handled: if i have installed both FTGL and GLTT, configure could detect both libraries and compile Gem with support for both (which doesn't really matter, since the GLTT-code would only be used if no FTGL is available) and (more importantly) link against both. ...bla bla...
i just noticed that this can easily be handled with the "execute-if-not-existant" flag in the AC-macro that checks for the existance of a certain library.
so forget this paragraph...
- 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.
good point; this cycle has certainly frustrated a lot of users when trying to compile Gem.
- 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.
well, we could of course do the compilation stage with "make -k" which would produce object-files for all compilable cpp-files, and link them together.
but i was rather talking about the mess in my (local) source-tree, which i don't want to tidy up... and it is not only me: jamie complained that he did a backup-copy of (say) "cube.cpp" which was automatically named (by finder) "copy of cube.cpp"; i think, not using "finder" for doing backup copies is not an option (at least, using configure should not keep anyone from using their favourite file-browser) so the options are: - delete the backup-copy entirely (why did i do it in the first place?) - compile with the backup-copy: this could break compilation due to the bad filename; what is worse is, that if compilation succeeds and we have a "copy of cube.o" besides the "cube.o"; which might seriously break auto-registering of the Gem-objects, and be very hard to find.
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.
well, i have a initial running version, i am not sure whether to check it in right now (jamie, does Gem now compile fine on tiger with the autoconf/make ? if so, could you commit any changes....)
Cheers, Guenter
but the real question i had was: how do i check the existance of a special function in a library ?
if i do in configure.in: AC_CHECK_LIB(GL, dududa)
then running configure just gives me: checking for dududa in -lGL... yes
which is not what i want (i'm pretty sure, that "dududa" is not defined in libGL)
so how does one do such function checks in a generic way ?
mfg.a.dr IOhannes