On Tue, 31 May 2005, IOhannes m zmoelnig wrote:
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)
Sorry :)
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.
Yes, the FTGL build system is not very good in general. I only put the PKG_CHECK_MODULES for packages that actually support pkgconfig, and thats how it should be IMO.
- 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.
No, its easier if the author of the software has taken the decision for me. Decisions need additional knowledge, and the knowledge I have as package maintainer can never match the knowledge of the author of the software.
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 can't remember what was wrong, but a commandline flag is not the solution to the problem.
i don't know the new debian build system, but i remember well that the old build scripts were usually filled with configure-options.
Normally they are standard configure options, like the path were to install things. Another advantage is to have options for non-free features (like ffmpeg has, for example).
and of course it should be possible to package Gem without the need to patch the source-code.
Yes it should. The current build system is just too messy and slow, thats why I changed it. I had written that in 98 or so, so I thought it is time for an update.
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.
I think that the mess in your source tree is a bad reason for having and overcomplicated build process.
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....)
I don't know if you should accept it. The point of accepting it is that you understand which problems it tries to solve and improve that. Otherwise it will only be a source of frustration.
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)
I have never seen such a behaviour from autoconf.
--- quote --- Macro: AC_CHECK_LIB (LIBRARY, FUNCTION, [ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND], [OTHER-LIBRARIES]) Depending on the current language(*note Language Choice::), try to ensure that the C, C++, or Fortran function FUNCTION is available by checking whether a test program can be linked with the library LIBRARY to get the function. LIBRARY is the base name of the library; e.g., to check for `-lmp', use `mp' as the LIBRARY argument. --- end quote ---
a serious bug in autoconf ?
Guenter
so how does one do such function checks in a generic way ?
mfg.a.dr IOhannes