On 11/06/2014 10:32 AM, David Roundy wrote:
Thanks for the link to that email thread, that helped me. My concerns
were pretty much those expressed by Mike at the time. At the time,
there was talk about eventually eliminating the old Tupfile format
entirely. Is that still a goal?
I don't think it's on the radar at this point, but Mike would be the one
to know.
My biggest concern with the lua parser is that it seems a very clumsy
alternative to the run-script option. True, it can be a little clumsy
generating strings, but writing a parser for an arbitrary language in
lua seems much clumsier. And that is precisely what one often wants
when writing rules: you want to know the inputs and outputs of a
given build, which often can be determined by parsing an input file.
True, you can write hokey regular expressions, but when those fail,
I'd like to be able to do it right.
I'm afraid I don't exactly understand where you're coming from here. I
don't think anyone was expecting to write a Python or Ruby parser in
Lua. Rather, if you had legacy Makefiles or build descriptors in some
other internal data file format, Lua could help parse those. I don't
believe there's any programming language out there that natively
supports loading Makefiles, so you'd be writing a parser no matter which
language you use.
As far as I can see from the lua parser docs, there is no way to
achieve the functionality in run-script, since I see no way to run an
external script. Is that an intentional limitation?
I think that the run-script ability wasn't included in Lua because they
were seen as alternatives; if you need to use run-script you probably
aren't using the Lua parser. It would probably be possible to move
run-script into the Lua parser in some form or another.
The only advantage that I can see in the lua parser is that it is
built in, so you don't require an external tool. But in most cases,
one will use an external tool to build your code anyhow, so that seems
a moderately weak advantage.
You mentioned the clumsiness of string interactions, but there's also
module and include management, accessing configuration, configuring
Tup's environment variable management, etc. Having to integrate
multiple tools through run-script is a significant burden for people
just trying Tup out. On platforms such as Windows for instance, you
also have to adjust shell environments and IDE paths for each
application you use, as does everyone else who contributes to the
project. You may have to deal with language version conflicts (is
python 3 or 2?).
If your concern is that it feels like a political statement or
favoritism towards Lua, I think that's unfounded. Lua is easily
sandboxed and is written in C, two major requirements for integrating.
Other languages, such as JS, Python, and Haskell were also considered.
I understand disliking having a language choice thrust upon you - I felt
the same way when considering CMake, Waf, Scons, etc. However, Tupfiles
themselves are a language choice, and it takes time and effort to learn
the ins and outs, advantages and weaknesses, common patterns and
workarounds. Regardless of the language choice, I believe a
standardized language like Lua is a good thing.
I'm not opposed to replacing the language at this point, for the
record. I have no strong attachment to Lua, but I don't think that the
current run-script functionality is sufficient. Ideas to improve Lua
integration or even proposals to replace Lua with something else to
improve the build definition experience are always welcome.
Cheers,
Rendaw
--
--
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.
