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
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
