[GEM-dev] Re: [GEM-cvs] Gem/src/Gnu configure.in

[=?X-UNKNOWN?Q?g=FCnter_geiger?=]

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
>