[PD-dev] pd buildsys: libdir / etags and the existing template

[dmotd]

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