[GEM-dev] the myths of configure

[IOhannes m zmoelnig]

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