On Sat, Jun 21, 2014 at 10:46 AM, Andrew Wagner <[email protected]> wrote:
Hello tup-using community!
>
> I would like to voice a concern that I have about the direction the open
> source community is taking regarding build systems.
>
> Almost every single new build system that is gaining any traction is built
> using an imperative, rather than declarative specification language.
> Consider:
>
> Build systems with DECLARATIVE specification languages:
> make
> shake (?)
> makepp (?)
> gyp
> ninja
> tup (w/Tupfile parser)
>
> Build systems with IMPERATIVE Build Systems:
> CMake
> Waf
> SCons
> tup (w/ lua parser)
>
> By their nature, declarative languages are way easier to parse
> recursively, and export in a new modified syntax (or export to an
> imperative language). This is not just theoretical; makepp and shake both
> parse makefiles.
>
> With a procedural specification language, it is easy to hammer out a huge
> pile of (often metaprogrammed) code that is difficult to read, and damn
> near impossible to parse automatically.
>
>
>
Hmm, sounds interesting. Can you clarify what exactly you mean by
declarative and imperative? Or why one is good for build descriptions and
the other is bad? I have seen both ugly and impossible to follow SCons
files as well as ugly and impossible to follow Makefiles, so at first
glance neither would seem to be a win. Plus in my mind, there isn't much
difference between:
: foreach *.c |> gcc -c %f -o %o |> %B.o
and:
tup.foreach_rule({'*.c'}, 'gcc -c %f -o %o', '%B.o')
Why is one good and the other a dark road we shouldn't go down?
I imagine it's not too surprising given the state of things, but I'm not a
very good student of what makes a for a good language/configuration design.
To me, the much more interesting & important aspect is what happens when
the rule is parsed. Ie: how to efficiently add the new commands described
by the rules to the DAG, how to remove stale commands, how to handle
conflicts between the commands, or circular dependencies, etc. I don't
think many (any?) other build systems take this approach to parsing -
usually they just parse the whole DAG every time, which is obviously dumb.
-Mike
--
--
tup-users mailing list
email: [email protected]
unsubscribe: [email protected]
options: http://groups.google.com/group/tup-users?hl=en
---
You received this message because you are subscribed to the Google Groups
"tup-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
