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

[Hans-Christoph Steiner]

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