On May 19, 2005, at 7:41 AM, IOhannes m zmölnig wrote:
Update of /cvsroot/pd-gem/Gem/src/Gnu In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv31109
Modified Files: acinclude.m4 aclocal.m4 configure Log Message: did better quoting, this should fix the issues with autoconf>2.53
...thanks for this! Ok, so I can now run autoconf with no big errors or warnings...but now I'll have to work on how to identify the opengl headers and such...plus, configure is picking up all the x11 stuff, and while that might be interesting as an intellectual exercise, I doubt anyone would want to run gem with x11 on osx: unfortunately, configuring with "-without-x" brings up "Gem will not run without X"...do you think that a "-with-osxnative" flag would be good to use to disable x11 and all of the "extra" media libs (except of course ftgl)?
...and one other thing before I dig into this over the weekend: it appears we can't do relative paths for --includedir?
configure: error: expected an absolute directory name for -- includedir: ../../../GemLibs:../../../pd-0.38-4/src
l8r, jamie
james tittle wrote:
...thanks for this! Ok, so I can now run autoconf with no big errors
good to hear that it is working
or warnings...but now I'll have to work on how to identify the opengl headers and such...plus, configure is picking up all the x11 stuff, and while that might be interesting as an intellectual exercise, I doubt anyone would want to run gem with x11 on osx: unfortunately, configuring with "-without-x" brings up "Gem will not run without X"...
oh, that is hardcoded by me in the configure.in; i can easily remove it (e.g. for Darwin)
do you think that a "-with-osxnative" flag would be good to use to disable x11 and all of the "extra" media libs (except of course ftgl)?
no i don't like that idea. if configure does not find (say) libmpeg3 then it will just "disable" the feature. on osx, i suppose configure should just find FTGL and the frameworks for openGL, quicktime (and whatever) and generates Makefile (and a configDarwin.h) out of this that respects all found libs.
...and one other thing before I dig into this over the weekend: it appears we can't do relative paths for --includedir?
configure: error: expected an absolute directory name for -- includedir: ../../../GemLibs:../../../pd-0.38-4/src
hmm, seems to work here, but the way it is handled is ugly anyhow. for now, you could just try to set some environment-variables before running configure: sthg like: #> export INCLUDES="-I../../../GemLibs -I../../../pd-0.38-4/src" #> ./configure
this _should_ work (and the modified INCLUDES _should_ go automatically into the generated Makefile)
mfg.adr IOhannes
james tittle wrote:
On May 19, 2005, at 7:41 AM, IOhannes m zmölnig wrote:
...thanks for this! Ok, so I can now run autoconf with no big errors or warnings...but now I'll have to work on how to identify the opengl headers and such...plus, configure is picking up all the x11 stuff, and while that might be interesting as an intellectual exercise, I doubt anyone would want to run gem with x11 on osx: unfortunately, configuring with "-without-x" brings up "Gem will not run without X"...do you think that a "-with-osxnative" flag would be good to use to disable x11 and all of the "extra" media libs (except of course ftgl)?
ok, so i have removed most of the hard dependencies (namely image-loading libraries) and made them soft (so if configure cannot find them, they will just be skipped)
X is still a hard dependency, but only on Linux ;-) (and sooner or later i want to get rid of that entirely)
the only remaining hard dependency should be openGL (of course); i have added some checks for those headers on osX (but very naively)
mfg.ads.r IOhannes
IOhannes m zmoelnig wrote:
the only remaining hard dependency should be openGL (of course); i have added some checks for those headers on osX (but very naively)
probably we should rather use something like this ? http://autoconf-archive.cryp.to/ax_check_gl.html
mfg.ads.r IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On May 23, 2005, at 11:21 AM, IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
the only remaining hard dependency should be openGL (of course); i have added some checks for those headers on osX (but very naively)
probably we should rather use something like this ? http://autoconf-archive.cryp.to/ax_check_gl.html
...hmm, I guess we could, but I think just looking for the headers like you did is ok...
...but now I've run into another problem: pre-10.4, math.h didn't define sinf() & friends...so we made "macosx_math.h" in GemLibs/ darwinStuff...now that it's defined on 10.4, I'm trying to conditionally find out if sinf is in math.h...I've done this by using a macro I found at the link you referred to above:
http://autoconf-archive.cryp.to/ac_check_func_in.html
...and tried:
dnl on osx, sinf() wasn't defined pre-10.4 if test `uname -s` == Darwin; then AC_CHECK_FUNC_IN(math.h, sinf, CXXFLAGS="$CXXFLAGS -DHAS_SINF", INCLUDES = "$INCLUDES ../../../GemLibs/ darwinStuff") fi
...but I haven't figured out where to put the "M4 source code"? I first tried to copy/paste from the webpage into acinclude.m4, but when I run "autoconf" again, it gives this:
tiggity:~/puredataDev/Gem/src/gnu tigital$ autoconf configure.in:611: error: possibly undefined macro: AC_CHECK_FUNC_IN If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation.
any ideas? jamie
On May 24, 2005, at 12:12 AM, james tittle wrote:
...but I haven't figured out where to put the "M4 source code"? I first tried to copy/paste from the webpage into acinclude.m4, but when I run "autoconf" again, it gives this:
...and now I've tried putting it into aclocal.m4 also, but again, it fails:
tiggity:~/puredataDev/Gem/src/gnu tigital$ autoconf configure.in:612: error: AC_LANG: unknown language: autoconf/lang.m4:123: _AC_LANG_SET is expanded from... autoconf/lang.m4:132: AC_LANG is expanded from... autoconf/general.m4:1799: AC_CACHE_VAL is expanded from... aclocal.m4:167: AC_CHECK_FUNC_IN is expanded from... configure.in:612: the top level autom4te-2.59: /sw/bin/gm4 failed with exit status: 1
well, hopefully there'll be an answer in the morning! jamie
james tittle wrote:
On May 23, 2005, at 11:21 AM, IOhannes m zmoelnig wrote:
...but now I've run into another problem: pre-10.4, math.h didn't define sinf() & friends...so we made "macosx_math.h" in GemLibs/ darwinStuff...now that it's defined on 10.4, I'm trying to conditionally find out if sinf is in math.h...I've done this by using a macro I found at the link you referred to above:
http://autoconf-archive.cryp.to/ac_check_func_in.html
...and tried:
dnl on osx, sinf() wasn't defined pre-10.4 if test `uname -s` == Darwin; then AC_CHECK_FUNC_IN(math.h, sinf, CXXFLAGS="$CXXFLAGS -DHAS_SINF", INCLUDES = "$INCLUDES ../../../GemLibs/ darwinStuff") fi
...but I haven't figured out where to put the "M4 source code"? I first tried to copy/paste from the webpage into acinclude.m4, but when I run "autoconf" again, it gives this:
tiggity:~/puredataDev/Gem/src/gnu tigital$ autoconf configure.in:611: error: possibly undefined macro: AC_CHECK_FUNC_IN If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation.
i guess it is like: paste the code into acinclude.m4 run "aclocal" run "autoconf" run "./configure"
mfg.a.dr. IOhannes
any ideas? jamie
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 current build system. It might need some adaptions for a non-linux target, but at least its a clean start.
Guenter
On Tue, 24 May 2005, IOhannes m zmoelnig wrote:
james tittle wrote:
On May 23, 2005, at 11:21 AM, IOhannes m zmoelnig wrote:
...but now I've run into another problem: pre-10.4, math.h didn't define sinf() & friends...so we made "macosx_math.h" in GemLibs/ darwinStuff...now that it's defined on 10.4, I'm trying to conditionally find out if sinf is in math.h...I've done this by using a macro I found at the link you referred to above:
http://autoconf-archive.cryp.to/ac_check_func_in.html
...and tried:
dnl on osx, sinf() wasn't defined pre-10.4 if test `uname -s` == Darwin; then AC_CHECK_FUNC_IN(math.h, sinf, CXXFLAGS="$CXXFLAGS -DHAS_SINF", INCLUDES = "$INCLUDES ../../../GemLibs/ darwinStuff") fi
...but I haven't figured out where to put the "M4 source code"? I first tried to copy/paste from the webpage into acinclude.m4, but when I run "autoconf" again, it gives this:
tiggity:~/puredataDev/Gem/src/gnu tigital$ autoconf configure.in:611: error: possibly undefined macro: AC_CHECK_FUNC_IN If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation.
i guess it is like: paste the code into acinclude.m4 run "aclocal" run "autoconf" run "./configure"
mfg.a.dr. IOhannes
any ideas? jamie
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
� 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)
- 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) ??
- 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 ?
- 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)
- shouldn't the script fail when not finding hard dependencies (e.g. openGL) ?
- 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)
- 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 ???
apart from that, it is surely cleaner (at least: shorter) than the old script. and it compiled fine
mfg.a.dr IOhannes
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
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
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
gÃŒnter geiger wrote:
On Tue, 31 May 2005, IOhannes m zmoelnig wrote:
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.
hmm. but debian provides an ftgl.pc, so this package supports pkgconfig. but when we decide to use PKG_CHECK_MODULES, then all pkgconfig must be supported by platforms for a specific package.
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.
yes i understand that. my idea was always, that autoconf should be able to figure out what is available on the current system and build accordingly. command line options should be _options_ (like in "optional") and not needed normally. but they should be there in order to enforce a special behaviour. (e.g. i am thinking of a "--without-GL" to disable the build of the openGL-wrapping objects for people who want a small binary and don't care for the openGL-wrapper at all)
e.g. you have commented out the support of libdv in the configure.in
I can't remember what was wrong, but a commandline flag is not the solution to the problem.
true. (but sometimes easiest...)
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).
what does this mean exactly ? can you disable non-free code in the ffmpeg-sources with a configure option ?
just for my interest: is the non-free section in Debian based on the source-code or the binaries. ? or: if i include non-free sources in my code but disable them (comments, ifdefs), is the code considered to be free then ?
I think that the mess in your source tree is a bad reason for having and overcomplicated build process.
well somehow yes; but i think the build process is for those who want to compile a package. and developers probably belong to the most important builders.
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.
a serious bug in autoconf ?
no
after some more investigation it seems to be a good reason for switching to a cleaner autonconf-script. i just tried "AC_CHECK_LIB(GL, dududa)" within another configure.in and it works as expected...
mfg.a.dsr IOhannes
IOhannes m zmoelnig wrote:
hmm. but debian provides an ftgl.pc, so this package supports pkgconfig. but when we decide to use PKG_CHECK_MODULES, then all pkgconfig must be supported by platforms for a specific package.
this should read:
but when we decide to use PKG_CHECK_MODULES, then a specific package must provide pkgconfig-support for all platforms (that use this package)
mfg.ads.r IOhannes
blech....
On May 24, 2005, at 2:21 AM, IOhannes m zmoelnig wrote:
i guess it is like: paste the code into acinclude.m4 run "aclocal" run "autoconf" run "./configure"
...thanx, but that didn't help...actually found another AC_CHECK_SYMBOL macro that didn't cause errors, but I can't get it to actually see if sinf is there or not! So I'm just going to try and add some magic header ("AvailabilityMacros.h") to deal with the sinf stuff...hopefully that'll work...
...btw, I figured out why I was getting a spurious "copy.o" in my / Manips makefile: configure is really, really, really dumb! In the finder I had duplicated "camera.cpp", which auto names the duplicated file to "camera copy.cpp"...configure then apparently got confused by a "name with a space", which really is pathetic in this day and age...again, why is this considered a good build system?
...hack hack hack hack hack... jamie
gem compile fix on 10.4: 2 weeks and counting!
james tittle wrote:
blech....
On May 24, 2005, at 2:21 AM, IOhannes m zmoelnig wrote:
i guess it is like: paste the code into acinclude.m4 run "aclocal" run "autoconf" run "./configure"
...btw, I figured out why I was getting a spurious "copy.o" in my / Manips makefile: configure is really, really, really dumb! In the finder I had duplicated "camera.cpp", which auto names the duplicated file to "camera copy.cpp"...configure then apparently got confused by a "name with a space", which really is pathetic in this day and age...again, why is this considered a good build system?
this has nothing to do with autoconf. it is just a simple script "makesource" which does "ls *.cpp >> Make.source" so you can either blame the script or ls.
a workaround might be using something like ls *.cpp | sed -e 's/ /\ /g' >> Make.source and consider all platforms that do not have "sed" installed to be inferior :)
mfg.a.dsr IOhannes
On May 24, 2005, at 12:55 PM, IOhannes m zmoelnig wrote:
james tittle wrote:
blech....
On May 24, 2005, at 2:21 AM, IOhannes m zmoelnig wrote:
i guess it is like: paste the code into acinclude.m4 run "aclocal" run "autoconf" run "./configure"
...btw, I figured out why I was getting a spurious "copy.o" in my / Manips makefile: configure is really, really, really dumb! In the finder I had duplicated "camera.cpp", which auto names the duplicated file to "camera copy.cpp"...configure then apparently got confused by a "name with a space", which really is pathetic in this day and age...again, why is this considered a good build system?
this has nothing to do with autoconf. it is just a simple script "makesource" which does "ls *.cpp >> Make.source" so you can either blame the script or ls.
a workaround might be using something like ls *.cpp | sed -e 's/ /\ /g' >> Make.source and consider all platforms that do not have "sed" installed to be inferior :)
...or at least make 'sed' a requirement for compiling gem ;)
...well, after taking a non-configure way out of the whole sinf() defining, I then discovered that I was using some undocumented altivec functions that somehow worked :-) There was an easy solution to that...and then there were quite a few other little easy problems (mostly to do with compiling files I'd never played with before, like the pix_filmNEW stuff), and before ya know it, I was down to the linking stage...
...for linking I had to hand enter some makefile stuff, with the end result being that it finally compiled, linked, and loaded! Whew...as soon as I can sort things out a bit more here (and test objects better), I'll start committing the changes...
jamie
Woo Hoo!!!!!!!!!!!
Thanks for all the work Jamie, if you knew how happy I would be to not worry about powerbuilder anymore. :) At least in the way I was worrying about it.
B.
james tittle wrote:
On May 24, 2005, at 12:55 PM, IOhannes m zmoelnig wrote:
james tittle wrote:
blech....
On May 24, 2005, at 2:21 AM, IOhannes m zmoelnig wrote:
i guess it is like: paste the code into acinclude.m4 run "aclocal" run "autoconf" run "./configure"
...btw, I figured out why I was getting a spurious "copy.o" in my / Manips makefile: configure is really, really, really dumb! In the finder I had duplicated "camera.cpp", which auto names the duplicated file to "camera copy.cpp"...configure then apparently got confused by a "name with a space", which really is pathetic in this day and age...again, why is this considered a good build system?
this has nothing to do with autoconf. it is just a simple script "makesource" which does "ls *.cpp >> Make.source" so you can either blame the script or ls.
a workaround might be using something like ls *.cpp | sed -e 's/ /\ /g' >> Make.source and consider all platforms that do not have "sed" installed to be inferior :)
...or at least make 'sed' a requirement for compiling gem ;)
...well, after taking a non-configure way out of the whole sinf() defining, I then discovered that I was using some undocumented altivec functions that somehow worked :-) There was an easy solution to that...and then there were quite a few other little easy problems (mostly to do with compiling files I'd never played with before, like the pix_filmNEW stuff), and before ya know it, I was down to the linking stage...
...for linking I had to hand enter some makefile stuff, with the end result being that it finally compiled, linked, and loaded! Whew...as soon as I can sort things out a bit more here (and test objects better), I'll start committing the changes...
jamie
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On May 24, 2005, at 2:21 AM, IOhannes m zmoelnig wrote:
i guess it is like: paste the code into acinclude.m4 run "aclocal" run "autoconf" run "./configure"
...other things:
...in configure.in, there is:
dnl i am not entirely sure, whether "-fPIC" is a good idea on ALL platforms CXXFLAGS="$CXXFLAGS -fPIC"
AC_SUBST(CXXFLAGS)
AC_SUBST(AFLAGS)
AC_SUBST(CXXDEBUG_FLAGS) AC_SUBST(CXXOPTIMIZE_FLAGS)
...if I read this right, it means that both debug and optimize flags are alway substituted? If so, how are we supposed to do a debug-only build, with no optimizations? Shouldn't we have a --debug flag for configure?
frustratedly puzzled, jamie
james tittle wrote:
On May 24, 2005, at 2:21 AM, IOhannes m zmoelnig wrote:
i guess it is like: paste the code into acinclude.m4 run "aclocal" run "autoconf" run "./configure"
...other things:
...in configure.in, there is:
dnl i am not entirely sure, whether "-fPIC" is a good idea on ALL platforms CXXFLAGS="$CXXFLAGS -fPIC"
AC_SUBST(CXXFLAGS)
AC_SUBST(AFLAGS)
AC_SUBST(CXXDEBUG_FLAGS) AC_SUBST(CXXOPTIMIZE_FLAGS)
...if I read this right, it means that both debug and optimize flags are alway substituted? If so, how are we supposed to do a debug-only build, with no optimizations? Shouldn't we have a --debug flag for configure?
well, i just split the flags into those that are responsible for debugging information and those that are responsible for optimization to make it a bit more readable. there is no special meaning behind it at all.
otoh, this makes it simple to add a "debug"-directive to the Makefile which just uses the debug-flags (and ignores the optimization flags)
mfg.asd.r IOhannes