Hey dmotd,
I'm cc'ing pd-dev, hope that's ok. That's the best place for discussions on this topic, IMHO.
On Sep 13, 2009, at 5:14 AM, dmotd wrote:
hi hans,
so i'm trying to finalize the template for the (improved) buildsys, i've attempted to keep the same function calls that are present in the current template but i have a few questions.
excellent :D
is the libdir metafile generator script still in use, because its no longer present in ext13 template? are there other meta data / data mining functions that may be useful in the future?
The script can still be used, but now the idea is for them to manually generated and maintained, then checked into SVN.
i'm not familiar with etags, i understand that they allow emacs to to search through relevant code, am i off the mark and is just globbing source code enough?
yes, its not just emacs, I think many other editors use them too. 'etags' is my name for it, I suppose there is a more proper name for the target.
dist seems useful, should there be an install directive too, and perhaps some meta data with the relevant environment vars which the lib was built.
obviously this template needs to be twisted a little for existing libs, but i was also thinking that there should be some extra vars for additional cflags / ldflags / etc.. as it seems a little too simplistic in its current state?
I wouldn't add anything that there isn't a direct use case for, what do you have in mind? The idea is to keep it as simple as possible so its easy to understand. People rarely spend time thinking about build systems, so its good to have them as simple as possible. Then if people want to have more complicated ones, they can add things. For example, once we get a Makefile template, then I think it would be good to have a configure.in/Makefile.in template for more complicated build needs.
in addition, as the buildsys i'm writing is non-recursive, so the top level builder knows a lot more about the externals tree than previously. there is potential to gather information during the build process, if you have any ideas please let me know.
'make' and autotools build systems should be recursive, that is how 'make' is supposed to work. It has the big advantage of being more modular, i.e. a library's Makefile easily can work standalone or part of a bigger whole.
i will contact you in the near future about putting my buildsys on the autobuild farm to test what works and not. unfortunately i can't work on this stuff except in my free time so i'm sorry if developments are painfully slow.
No worries, glad to see any progress :).
.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
i'm not familiar with etags, i understand that
never heard about etags, only know about ctags (Exhuberant Ctags: http://ctags.sourceforge.net/) vim supports ctags natively
dist seems useful, should there be an install directive too, and perhaps some meta data with the relevant environment vars which the lib was built.
obviously this template needs to be twisted a little for existing libs, but i was also thinking that there should be some extra vars for additional cflags / ldflags / etc.. as it seems a little too simplistic in its current state?
yep. some notes about vars:
1) always respect what environment vars are. i.e. don't override CFLAGS, LDFLAGS.... eventually accept additional CFLAGS as a parameter, that allows overriding flags defined in Makefile.
examples:
bad: CFLAGS = -fomit-frame-pointer -DPD good: CFLAGS += -fomit-frame-pointer -DPD
better: CFLAGS += -fomit-frame-pointer -DPD $(MORE_CFLAGS) allows overriding some flag, example: make MORE_CFLAGS="-fno-omit-frame-pointer"
2) don't put architecture dependant flags, or optimization flags. if you have to put optimization flags, always allow to override them like described above with $(MORE_CFLAGS)
examples:
bad: CFLAGS += -mcpu=crtex-m3 bad: CFLAGS += -march=nocona
3) always respect DESTDIR in install. it costs you nothing and is transparent for those not using it.
example:
install: install ... $(LIB) $(DESTDIR)/usr/lib/pd/extra/...
configure.in/Makefile.in template for more complicated build
++
are you writing some ac/am macros specific to pd as well?
ciao
Hans-Christoph Steiner wrote:
On Sep 13, 2009, at 5:14 AM, dmotd wrote:
i'm not familiar with etags, i understand that they allow emacs to to search through relevant code, am i off the mark and is just globbing source code enough?
yes, its not just emacs, I think many other editors use them too. 'etags' is my name for it, I suppose there is a more proper name for the target.
okay, i don't have the 'etags' program on my system, so i just wanted to confirm that..
obviously this template needs to be twisted a little for existing libs, but i was also thinking that there should be some extra vars for additional cflags / ldflags / etc.. as it seems a little too simplistic in its current state?
I wouldn't add anything that there isn't a direct use case for, what do you have in mind? The idea is to keep it as simple as possible so its easy to understand. People rarely spend time thinking about build systems, so its good to have them as simple as possible. Then if people want to have more complicated ones, they can add things. For example, once we get a Makefile template, then I think it would be good to have a configure.in/Makefile.in template for more complicated build needs.
that's fine, i was just wondering if it should be more explicit - even if it is just blank, so that devs know where to put their own custom vars should they need to.
in addition, as the buildsys i'm writing is non-recursive, so the top level builder knows a lot more about the externals tree than previously. there is potential to gather information during the build process, if you have any ideas please let me know.
'make' and autotools build systems should be recursive, that is how 'make' is supposed to work. It has the big advantage of being more modular, i.e. a library's Makefile easily can work standalone or part of a bigger whole.
'make' was designed for small projects and has since been employed in much larger ones, the recursive make is not how its 'supposed to work', its a feature - with its own set of flaws.
the argument against recursive makefiles is well stated here:
http://miller.emu.id.au/pmiller/books/rmch/
its not my intention to make anything less 'modular', i have addressed the need for each lib to be to be self contained and if its desirable a recursive system could easily be reemployed. in fact it should be easier for individuals to maintain their own code and builder scripts without having to worry too much about the parent builder scripts.
in any case, where it is necessary (autotools / sophisticated build mechanisms) the recursive technique is taken up again.
there are numerous benefits of employing a non-recursive technique, it makes the buildsystem more aware of the codebase, it avoids duplication of code across many makefiles (and the maintanence issues that causes), it allows writing macros and functions that are standard across each library, and it is the first step towards a nice menu driven configuration system - which is the next phase of my developments on the buildsys.
please rest assured that i am not planning to just dump this on the svn and expect immediate take up, i will provide you with a test case so that you can inspect the changes and provide feedback before anything is commited.
i think you will understand better when you see something concrete. i'll endeavour to finish up asap!
cheers,
dmotd
On Sep 13, 2009, at 9:57 PM, dmotd wrote:
Hans-Christoph Steiner wrote:
On Sep 13, 2009, at 5:14 AM, dmotd wrote:
i'm not familiar with etags, i understand that they allow emacs to to search through relevant code, am i off the mark and is just globbing source code enough?
yes, its not just emacs, I think many other editors use them too. 'etags' is my name for it, I suppose there is a more proper name for the target.
okay, i don't have the 'etags' program on my system, so i just wanted to confirm that..
I guess etags is the ctags equivalent that comes with emacs. Including that stuff in the Makefile is optional.
obviously this template needs to be twisted a little for existing libs, but i was also thinking that there should be some extra vars for additional cflags / ldflags / etc.. as it seems a little too simplistic in its current state?
I wouldn't add anything that there isn't a direct use case for, what do you have in mind? The idea is to keep it as simple as possible so its easy to understand. People rarely spend time thinking about build systems, so its good to have them as simple as possible. Then if people want to have more complicated ones, they can add things. For example, once we get a Makefile template, then I think it would be good to have a configure.in/Makefile.in template for more complicated build needs.
that's fine, i was just wondering if it should be more explicit - even if it is just blank, so that devs know where to put their own custom vars should they need to.
I haven't seen a reason to have too many different version. If we do use more than just the standard CFLAGS, etc. we should use the ones that the autotools uses since that's a super common standard.
in addition, as the buildsys i'm writing is non-recursive, so the top level builder knows a lot more about the externals tree than previously. there is potential to gather information during the build process, if you have any ideas please let me know.
'make' and autotools build systems should be recursive, that is how 'make' is supposed to work. It has the big advantage of being more modular, i.e. a library's Makefile easily can work standalone or part of a bigger whole.
'make' was designed for small projects and has since been employed in much larger ones, the recursive make is not how its 'supposed to work', its a feature - with its own set of flaws.
the argument against recursive makefiles is well stated here:
http://miller.emu.id.au/pmiller/books/rmch/
its not my intention to make anything less 'modular', i have addressed the need for each lib to be to be self contained and if its desirable a recursive system could easily be reemployed. in fact it should be easier for individuals to maintain their own code and builder scripts without having to worry too much about the parent builder scripts.
in any case, where it is necessary (autotools / sophisticated build mechanisms) the recursive technique is taken up again.
there are numerous benefits of employing a non-recursive technique, it makes the buildsystem more aware of the codebase, it avoids duplication of code across many makefiles (and the maintanence issues that causes), it allows writing macros and functions that are standard across each library, and it is the first step towards a nice menu driven configuration system - which is the next phase of my developments on the buildsys.
please rest assured that i am not planning to just dump this on the svn and expect immediate take up, i will provide you with a test case so that you can inspect the changes and provide feedback before anything is commited.
i think you will understand better when you see something concrete. i'll endeavour to finish up asap!
Ok, sounds like a good plan.
.hc
----------------------------------------------------------------------------
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
-
dmotd -
Hans-Christoph Steiner -
mescalinum＠gmail.com