during the debian packaging of externals i once more stumbled across one of my many problems with make, which i was never able to solve in a satisfactory way.
it is: the Makefile uses CFLAGS and LDFLAGS to set crucial flags to the build process e.g. LDFLAGS uses "-Wl,--export-dynamic -shared" to build shared libraries (in our case: externals)
however, some meta build processes (like debian packaging) explicitely set these FLAGS to what they think are good optimization/debugging defaults e.g. make get's called like $ /usr/bin/make LDFLAGS="" CFLAGS="-I/usr/local/include"
this however effectively disables all the settings done within the Makefile, which leads to not passing "-Wl,--export-dynamic -shared" to the linker, leading to a fatal error when linking.
what is the canonical way to use the passed FLAGS and at the same time adding whatever is needed? something like 'PD_LDFLAGS="-Wl,--export-dynamic -shared $(LDFLAGS)"' and then consequently using $(PD_LDFLAGS) in the linking stage?
this is such a fundamental thing that i'm sure there has to be an elegant solution to this but i never came across one. the PD_LDFLAGS seems a bit like a kludge to me.
fgmsdr IOhannes
On Dec 1, 2010, at 12:00 PM, IOhannes m zmoelnig wrote:
during the debian packaging of externals i once more stumbled across one of my many problems with make, which i was never able to solve in a satisfactory way.
it is: the Makefile uses CFLAGS and LDFLAGS to set crucial flags to the build process e.g. LDFLAGS uses "-Wl,--export-dynamic -shared" to build shared libraries (in our case: externals)
however, some meta build processes (like debian packaging) explicitely set these FLAGS to what they think are good optimization/debugging defaults e.g. make get's called like $ /usr/bin/make LDFLAGS="" CFLAGS="-I/usr/local/include"
this however effectively disables all the settings done within the Makefile, which leads to not passing "-Wl,--export-dynamic -shared" to the linker, leading to a fatal error when linking.
what is the canonical way to use the passed FLAGS and at the same time adding whatever is needed? something like 'PD_LDFLAGS="-Wl,--export-dynamic -shared $(LDFLAGS)"' and then consequently using $(PD_LDFLAGS) in the linking stage?
this is such a fundamental thing that i'm sure there has to be an elegant solution to this but i never came across one. the PD_LDFLAGS seems a bit like a kludge to me.
What optimization do you need to include in LDFLAGS? I can't think of any. I think the best source of info for this would be to see what Debian builders set as LDFLAGS.
But if you really want to have all the possibilities for overriding things, then go with autotools, especially with automake. They generate makefiles that have lots of room for customization. From my point of view the Makefile template was never intended to work in all situations, only simple libraries that don't have special dependencies.
.hc
----------------------------------------------------------------------------
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/01/2010 06:16 PM, Hans-Christoph Steiner wrote:
On Dec 1, 2010, at 12:00 PM, IOhannes m zmoelnig wrote:
this is such a fundamental thing that i'm sure there has to be an elegant solution to this but i never came across one. the PD_LDFLAGS seems a bit like a kludge to me.
What optimization do you need to include in LDFLAGS? I can't think of
"optimization" being a general term here for whatever tweaks the user sees fit. with CFLAGS these are definitely optimizations, with LDFLAGS i don't know.
any. I think the best source of info for this would be to see what Debian builders set as LDFLAGS.
the thing is, some of them (e.g. CDBS) do set LDFLAGS to "" (nothing). this is when i discovered the problem when trying to cdbs'ify pd-arraysize, because the build would fail. (never mind my cdbs'ifying that; i'm trying to build a common cdbs-snippet for more easy packaging in debian)
But if you really want to have all the possibilities for overriding things, then go with autotools, especially with automake. They generate makefiles that have lots of room for customization. From my point of view the Makefile template was never intended to work in all situations, only simple libraries that don't have special dependencies.
i'm really not trying to use autotools here, as that is definitely an overkill in most situations. however, afaict, CFLAGS and LDFLAGS are commonly meant to be settable by the user, so setting those should not break the build system.
the problem also is not template Makefile centric (though i stumbled over the problem with the template Makefile in this special case; however, in the past, i have stumbled over this problem with other Makefiles as well) autotools will kind of automatically take care of those things, but since this is such a common case, i do believe that there must be a elegant, vanilla make solution for the problem.
i'm really not trying to invent problems but to solve them.
fgmasdr IOhannes
On Dec 1, 2010, at 1:53 PM, IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/01/2010 06:16 PM, Hans-Christoph Steiner wrote:
On Dec 1, 2010, at 12:00 PM, IOhannes m zmoelnig wrote:
this is such a fundamental thing that i'm sure there has to be an elegant solution to this but i never came across one. the PD_LDFLAGS seems a bit like a kludge to me.
What optimization do you need to include in LDFLAGS? I can't think of
"optimization" being a general term here for whatever tweaks the user sees fit. with CFLAGS these are definitely optimizations, with LDFLAGS i don't know.
any. I think the best source of info for this would be to see what Debian builders set as LDFLAGS.
the thing is, some of them (e.g. CDBS) do set LDFLAGS to "" (nothing). this is when i discovered the problem when trying to cdbs'ify pd-arraysize, because the build would fail. (never mind my cdbs'ifying that; i'm trying to build a common cdbs-snippet for more easy packaging in debian)
But if you really want to have all the possibilities for overriding things, then go with autotools, especially with automake. They generate makefiles that have lots of room for customization. From my point of view the Makefile template was never intended to work in all situations, only simple libraries that don't have special dependencies.
i'm really not trying to use autotools here, as that is definitely an overkill in most situations. however, afaict, CFLAGS and LDFLAGS are commonly meant to be settable by the user, so setting those should not break the build system.
the problem also is not template Makefile centric (though i stumbled over the problem with the template Makefile in this special case; however, in the past, i have stumbled over this problem with other Makefiles as well) autotools will kind of automatically take care of those things, but since this is such a common case, i do believe that there must be a elegant, vanilla make solution for the problem.
i'm really not trying to invent problems but to solve them.
I guess the problem that you are having isn't clear to me. Is it related to the default CFLAGS and LDFLAGS that CDBS passes to Makefiles? debhelper seems to be better about this, I didn't have to touch CFLAGS or LDFLAGS with the template's short-form dh debian/rules.
If you want CDBS to be able to override CFLAGS and LDFLAGS, just add what's needed in the CDBS files, i.e. -Wl,--export-dynamic. The template Makefile is complicated because it supports many platforms. CDBS is for building on a pretty narrow platform, so it makes sense to me to include the specifics in the CDBS files.
One thing that should be set regardless of CFLAGS is -DPD and - DVERSION. Perhaps those should just be added to the build rules directly.
.hc
----------------------------------------------------------------------------
There is no way to peace, peace is the way. -A.J. Muste
IOhannes m zmölnig wrote:
however, afaict, CFLAGS and LDFLAGS are commonly meant to be settable by the user, so setting those should not break the build system.
Exactly. Therefore a Makefile should *not* set CFLAGS, CXXFLAGS, LDFLAGS and the like, or only set them to some reasonable defaults which can be freely overridden by the user. Of course this means that build-specific options must be passed in the corresponding Makfile rules in addition to these variables.
This is only a convention, of course, but it's part of the GNU Coding Standards [1] and supported by automake and other build and packaging utilities. Users and packagers have come to expect that it works that way, so it's a good idea to follow this rule if you want to make users happy.
[1] http://www.gnu.org/prep/standards/html_node/Command-Variables.html
Albert
On 2010-12-01 23:56, Albert Graef wrote:
IOhannes m zmölnig wrote:
however, afaict, CFLAGS and LDFLAGS are commonly meant to be settable by the user, so setting those should not break the build system.
Exactly. Therefore a Makefile should *not* set CFLAGS, CXXFLAGS, LDFLAGS and the like, or only set them to some reasonable defaults which can be freely overridden by the user. Of course this means that build-specific options must be passed in the corresponding Makfile rules in addition to these variables.
finarlly someone who understands me!
This is only a convention, of course, but it's part of the GNU Coding Standards
ha, thank you very much for the pointer. i think the curcial part is: "If there are C compiler options that must be used for proper compilation of certain files, do not include them in CFLAGS. Users expect to be able to specify CFLAGS freely themselves."
and i think this can also be extrapolated for any of the standard flags (CPPFLAGS, CFLAGS, CXXFLAGS, LDFLAGS)
masdr IOhannes
On Dec 2, 2010, at 4:16 AM, IOhannes m zmoelnig wrote:
On 2010-12-01 23:56, Albert Graef wrote:
IOhannes m zmölnig wrote:
however, afaict, CFLAGS and LDFLAGS are commonly meant to be settable by the user, so setting those should not break the build system.
Exactly. Therefore a Makefile should *not* set CFLAGS, CXXFLAGS, LDFLAGS and the like, or only set them to some reasonable defaults which can be freely overridden by the user. Of course this means that build- specific options must be passed in the corresponding Makfile rules in addition to these variables.
finarlly someone who understands me!
This is only a convention, of course, but it's part of the GNU Coding Standards
ha, thank you very much for the pointer. i think the curcial part is: "If there are C compiler options that must be used for proper compilation of certain files, do not include them in CFLAGS. Users expect to be able to specify CFLAGS freely themselves."
and i think this can also be extrapolated for any of the standard flags (CPPFLAGS, CFLAGS, CXXFLAGS, LDFLAGS)
So what do you propose? I for one am really sick of build system stuff. What we have works quite well on many platform, but yes, its not perfect. About changes to the template Makefile, last time IOhannes you changed it, you didn't test it well and it had a bug where the help files didn't get included and it didn't throw and error. That caused me to have to re-issue Pd-extended releases to make sure all the help patches were included, which I was not happy about.
So basically, if anyone wants to improve the template Makefile, that's good, but they need to _thoroughly_ test all changes to it on multiple platforms. Really, the way to do it is to do these changes as part of a library, then once they are well tested and ironed out, include them in the template Makefile.
.hc
----------------------------------------------------------------------------
"We have nothing to fear from love and commitment." - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill
morning all,
On 2010-12-02 20:18:45, Hans-Christoph Steiner hans@at.or.at appears to have written:
On Dec 2, 2010, at 4:16 AM, IOhannes m zmoelnig wrote:
On 2010-12-01 23:56, Albert Graef wrote:
IOhannes m zmölnig wrote: This is only a convention, of course, but it's part of the GNU Coding Standards
i think the curcial part is: "If there are C compiler options that must be used for proper compilation of certain files, do not include them in CFLAGS. Users expect to be able to specify CFLAGS freely themselves."
and i think this can also be extrapolated for any of the standard flags (CPPFLAGS, CFLAGS, CXXFLAGS, LDFLAGS)
So what do you propose?
Maybe I'm misreading this thread, but wasn't there something like:
something like 'PD_LDFLAGS="-Wl,--export-dynamic -shared $(LDFLAGS)"' and then consequently using $(PD_LDFLAGS) in the linking stage?
in IOhannes' original posting? Use of a dedicated internal variable has a lot of precedents (e.g. automake's use of AM_CFLAGS etc.), and should in fact be *more* robust than the status quo...
I for one am really sick of build system stuff. What we have works quite well on many platform, but yes, its not perfect. About changes to the template Makefile, last time
[snip]
Easy does it... please step away from any sharp objects or small furry animals for a moment... OK, now: bugs happen. I read this thread primarily as an attempt to ensure that *fewer* bugs happen in the future, and I think replacing non-standard uses of standard *FLAGS variables in any build system is a worthwhile endeavor in that respect.
@IOhannes: sorry about my bogus "+=" suggestion; posted without testing it first :-/
marmosets, Bryan
On Dec 2, 2010, at 3:11 PM, Bryan Jurish wrote:
morning all,
On 2010-12-02 20:18:45, Hans-Christoph Steiner hans@at.or.at appears to have written:
On Dec 2, 2010, at 4:16 AM, IOhannes m zmoelnig wrote:
On 2010-12-01 23:56, Albert Graef wrote:
IOhannes m zmölnig wrote: This is only a convention, of course, but it's part of the GNU Coding Standards
i think the curcial part is: "If there are C compiler options that must be used for proper compilation of certain files, do not include them in CFLAGS. Users expect to be able to specify CFLAGS freely themselves."
and i think this can also be extrapolated for any of the standard flags (CPPFLAGS, CFLAGS, CXXFLAGS, LDFLAGS)
So what do you propose?
Maybe I'm misreading this thread, but wasn't there something like:
something like 'PD_LDFLAGS="-Wl,--export-dynamic -shared $ (LDFLAGS)"' and then consequently using $(PD_LDFLAGS) in the linking stage?
in IOhannes' original posting? Use of a dedicated internal variable has a lot of precedents (e.g. automake's use of AM_CFLAGS etc.), and should in fact be *more* robust than the status quo...
I for one am really sick of build system stuff. What we have works quite well on many platform, but yes, its not perfect. About changes to the template Makefile, last time
[snip]
Easy does it... please step away from any sharp objects or small furry animals for a moment... OK, now: bugs happen. I read this thread primarily as an attempt to ensure that *fewer* bugs happen in the future, and I think replacing non-standard uses of standard *FLAGS variables in any build system is a worthwhile endeavor in that respect.
Sorry for the complaint, the bug in question cost me a full day of time re-doing really unfun stuff. That's a full day of my free, unpaid time. Code has bugs, therefore it needs testing, that's all I'm saying.
So I say take the template Makefile and go nuts with it, fix all the bugs add features, but do it in a branch, thoroughly test it, and then we take it from there.
.hc
@IOhannes: sorry about my bogus "+=" suggestion; posted without testing it first :-/
marmosets, Bryan
-- Bryan Jurish "There is *always* one more bug." jurish@uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology
----------------------------------------------------------------------------
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
On 12/02/2010 09:40 PM, Hans-Christoph Steiner wrote:
On Dec 2, 2010, at 3:11 PM, Bryan Jurish wrote:
Maybe I'm misreading this thread, but wasn't there something like:
something like 'PD_LDFLAGS="-Wl,--export-dynamic -shared $(LDFLAGS)"' and then consequently using $(PD_LDFLAGS) in the linking stage?
yes, this would be my suggestion.
Sorry for the complaint, the bug in question cost me a full day of time re-doing really unfun stuff. That's a full day of my free, unpaid time. Code has bugs, therefore it needs testing, that's all I'm saying.
sure. however, in order to properly test, it would be great to have a test defined (even if it only was an instruction like, apply your changes to library X (because this uses feature A) and library Y (using feature A & B), then run $ make $ make clean $ make install $ make uninstall $ make install DESTDIR="/tmp" $ make uninstall DESTDIR="/tmp" $ make dist and see if all this succeeds.
doing a "thorough test" on the template Makefile without having a test defined, is probably taking more time then a full day (and yes, i do a lot of work in my free unpaid time as well)
So I say take the template Makefile and go nuts with it, fix all the bugs add features, but do it in a branch, thoroughly test it, and then we take it from there.
i switched the build-system of iem/syslog to my modded version of the template Makefile and afaict, "everything" works:
https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/externals/iem/...
"everything" excludes the 'uninstall' target (non-existant it seems) and an unnecessary complicated procedure to install into /usr/lib/pd/extra (though i won't change that for now)
sidenote: in this makefile i am using ALL_*FLAGS rather than PD_*FLAGS; i have no opinion whatsoever on the exact prefix of the variables; ALL_* is "suggested" on the Gnu standards page, and PD_* being more "Pd" than "Pd-external".
probably "PDEXT_" would be a proper prefix.
@IOhannes: sorry about my bogus "+=" suggestion; posted without testing it first :-/
np. it's what i would have suggested myself as well, just to find out that it didn't work. i prefer one person to find out and communicate, to two persons having to go through all steps to find out.
mgfasd IOhannes
If you want to test it on various platforms at once, please msg me and we can easily set it up in buildbot (which is not the effective autobuild system yet, but it's quite worked out). We will just need to have the stuff available in some kind of repo.
Andras
2010/12/3 IOhannes zmölnig zmoelnig@iem.at
On 12/02/2010 09:40 PM, Hans-Christoph Steiner wrote:
On Dec 2, 2010, at 3:11 PM, Bryan Jurish wrote:
Maybe I'm misreading this thread, but wasn't there something like:
something like 'PD_LDFLAGS="-Wl,--export-dynamic -shared $(LDFLAGS)"' and then consequently using $(PD_LDFLAGS) in the linking stage?
yes, this would be my suggestion.
Sorry for the complaint, the bug in question cost me a full day of time re-doing really unfun stuff. That's a full day of my free, unpaid time. Code has bugs, therefore it needs testing, that's all I'm saying.
sure. however, in order to properly test, it would be great to have a test defined (even if it only was an instruction like, apply your changes to library X (because this uses feature A) and library Y (using feature A & B), then run $ make $ make clean $ make install $ make uninstall $ make install DESTDIR="/tmp" $ make uninstall DESTDIR="/tmp" $ make dist and see if all this succeeds.
doing a "thorough test" on the template Makefile without having a test defined, is probably taking more time then a full day (and yes, i do a lot of work in my free unpaid time as well)
So I say take the template Makefile and go nuts with it, fix all the bugs add features, but do it in a branch, thoroughly test it, and then we take it from there.
i switched the build-system of iem/syslog to my modded version of the template Makefile and afaict, "everything" works:
https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/externals/iem/...
"everything" excludes the 'uninstall' target (non-existant it seems) and an unnecessary complicated procedure to install into /usr/lib/pd/extra (though i won't change that for now)
sidenote: in this makefile i am using ALL_*FLAGS rather than PD_*FLAGS; i have no opinion whatsoever on the exact prefix of the variables; ALL_* is "suggested" on the Gnu standards page, and PD_* being more "Pd" than "Pd-external".
probably "PDEXT_" would be a proper prefix.
@IOhannes: sorry about my bogus "+=" suggestion; posted without testing it first :-/
np. it's what i would have suggested myself as well, just to find out that it didn't work. i prefer one person to find out and communicate, to two persons having to go through all steps to find out.
mgfasd IOhannes
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On 12/03/2010 05:44 PM, András Murányi wrote:
If you want to test it on various platforms at once, please msg me and we can easily set it up in buildbot (which is not the effective autobuild system yet, but it's quite worked out). We will just need to have the stuff available in some kind of repo.
thanks for the offer. the syslog external/library that uses the modded Makefile is already in the repository.
nevertheless, i don't know what to test :-(
fgkasdr IOhannes
2010/12/3 IOhannes zmölnig zmoelnig@iem.at
On 12/03/2010 05:44 PM, András Murányi wrote:
If you want to test it on various platforms at once, please msg me and we can easily set it up in buildbot (which is not the effective autobuild system yet, but it's quite worked out). We will just need to have the stuff available in some kind of repo.
thanks for the offer. the syslog external/library that uses the modded Makefile is already in the repository.
nevertheless, i don't know what to test :-(
fgkasdr IOhannes
...and my knowledge of Makefiles etc is almost zero, but if you want to fork new Makefile logics and see if they build alrite on various platforms, i can put the source and the build steps in buildbot quickly and you can test&modify until it works. Just tell me.
Andras
On Dec 3, 2010, at 5:03 AM, IOhannes zmölnig wrote:
On 12/02/2010 09:40 PM, Hans-Christoph Steiner wrote:
On Dec 2, 2010, at 3:11 PM, Bryan Jurish wrote:
Maybe I'm misreading this thread, but wasn't there something like:
something like 'PD_LDFLAGS="-Wl,--export-dynamic -shared $ (LDFLAGS)"' and then consequently using $(PD_LDFLAGS) in the linking stage?
yes, this would be my suggestion.
Sorry for the complaint, the bug in question cost me a full day of time re-doing really unfun stuff. That's a full day of my free, unpaid time. Code has bugs, therefore it needs testing, that's all I'm saying.
sure. however, in order to properly test, it would be great to have a test defined (even if it only was an instruction like, apply your changes to library X (because this uses feature A) and library Y (using feature A & B), then run $ make $ make clean $ make install $ make uninstall $ make install DESTDIR="/tmp" $ make uninstall DESTDIR="/tmp" $ make dist and see if all this succeeds.
doing a "thorough test" on the template Makefile without having a test defined, is probably taking more time then a full day (and yes, i do a lot of work in my free unpaid time as well)
For the bug in question, we'd need a way to test for changes in which files are installed and included in the dist tarball. I guess the nightly build could log the file list and then a compare could be scripted. I haven't thought of a great way to do this.
So I say take the template Makefile and go nuts with it, fix all the bugs add features, but do it in a branch, thoroughly test it, and then we take it from there.
i switched the build-system of iem/syslog to my modded version of the template Makefile and afaict, "everything" works:
https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/externals/iem/...
"everything" excludes the 'uninstall' target (non-existant it seems) and an unnecessary complicated procedure to install into /usr/lib/pd/extra (though i won't change that for now)
sidenote: in this makefile i am using ALL_*FLAGS rather than PD_*FLAGS; i have no opinion whatsoever on the exact prefix of the variables; ALL_* is "suggested" on the Gnu standards page, and PD_* being more "Pd" than "Pd-external".
probably "PDEXT_" would be a proper prefix.
I like the ALL_ prefix as long as it really means "all", meaning something like this:
ALL_CFLAGS = $(INTERNAL_CFLAGS) $(X_CFLAGS) $(T_CFLAGS) $(CFLAGS)
.hc
----------------------------------------------------------------------------
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
moin folks,
On 2010-12-01 18:00:21, IOhannes m zmoelnig zmoelnig@iem.at appears to have written:
what is the canonical way to use the passed FLAGS and at the same time adding whatever is needed? something like 'PD_LDFLAGS="-Wl,--export-dynamic -shared $(LDFLAGS)"' and then consequently using $(PD_LDFLAGS) in the linking stage?
That's probably the safest way, but a bit unwieldy... I would tend to favor:
LDFLAGS += -Wl,--export-dynamic
in the local (pd) Makefile, just in case there happens to be something important in the caller's (packager's) flags... but maybe the "+=" operator is a GNU make extension? Maybe ":=" in the Makefile would work to append to any predefined LDFLAGS? Or is ":=" also a GNU extension... I don't really ever write makefiles for anything other than GNU make, so I'm not too sure...
On 2010-12-01 18:16:47, Hans-Christoph Steiner hans@at.or.at appears to have written:
But if you really want to have all the possibilities for overriding things, then go with autotools, especially with automake. They generate makefiles that have lots of room for customization.
+1
... but I'd like to note that autotools involve a whole new dimension of headaches with *FLAGS variables. In particular, AC_PROG_CC() sets CFLAGS="-g -O2" by default for gcc (if it's otherwise unset), which is not the kind of default I usually prefer. You can reset it explicitly in configure.ac or Makefile.am (say CFLAGS="-O2"), *but* then you lose any CFLAGS your caller might have actually passed in explicitly (e.g. CFLAGS="-O32767 -fSuperDuperPooperScooper -WWillRobinson"). I usually work around this with shell hackery in configure.ac -- gory details in externals/moocow/common/m4/{ax_hack_cflags,ax_pd_external}.m4 ... so yes: autotools are flexible enough to handle this kind of thing, but not entirely without wailing and/or gnashing of teeth...
marmosets, Bryan
On 2010-12-01 22:38, Bryan Jurish wrote:
moin folks,
On 2010-12-01 18:00:21, IOhannes m zmoelnig zmoelnig@iem.at appears to have written:
what is the canonical way to use the passed FLAGS and at the same time adding whatever is needed? something like 'PD_LDFLAGS="-Wl,--export-dynamic -shared $(LDFLAGS)"' and then consequently using $(PD_LDFLAGS) in the linking stage?
That's probably the safest way, but a bit unwieldy... I would tend to favor:
LDFLAGS += -Wl,--export-dynamic
yes that was my first guess. unfortunately this does not work at all. it seems that make will simply ignore any assignments to a variable that has been defined via cmdline arguments (not via environment variables though, which have low precedence)
in the local (pd) Makefile, just in case there happens to be something important in the caller's (packager's) flags... but maybe the "+=" operator is a GNU make extension? Maybe ":=" in the Makefile would work
the same as above. really the only way i found to do an assignment to a variable declared like $ make MYVAR=foo was to add the "override" directive in the Makefile.
to append to any predefined LDFLAGS? Or is ":=" also a GNU extension... I don't really ever write makefiles for anything other than GNU make, so I'm not too sure...
and all this without even bothering about GNU extensions yet!
On 2010-12-01 18:16:47, Hans-Christoph Steiner hans@at.or.at appears to have written:
But if you really want to have all the possibilities for overriding things, then go with autotools, especially with automake. They generate makefiles that have lots of room for customization.
+1
again, i do like autoconf but sometimes it is really out of question. right now i am _also_ talking about the template Makefile (and how to make this more robust and behave like expected), and autotools is a no-go here.
... but I'd like to note that autotools involve a whole new dimension of headaches with *FLAGS variables. In particular, AC_PROG_CC() sets CFLAGS="-g -O2" by default for gcc (if it's otherwise unset), which is not the kind of default I usually prefer. You can reset it explicitly in configure.ac or Makefile.am (say CFLAGS="-O2"), *but* then you lose any CFLAGS your caller might have actually passed in explicitly (e.g. CFLAGS="-O32767 -fSuperDuperPooperScooper -WWillRobinson"). I usually
i think this is basically the same problem as i have.
the user should be able to set the CFLAGS they like, while at the same time when doing so they should not be breaking the build system "by default", which they are currently doing.
mfgsdr IOhannes
-
Albert Graef -
András Murányi -
Bryan Jurish -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
IOhannes zmölnig