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