http://elua-development.15.s1.nabble.com/Mixed-arm-and-thumb-code-tp2537643p2551442.html
On Sat, Mar 28, 2009 at 5:05 PM, Bogdan Marinescu
<[hidden email]> wrote:
The reason most people (me included) don't remember stuff about make is because not vary many people spend time writing build scripts.
You're right, but IMO there's a level beyond this, a more philosophical one, that takes into account the overall design principles and usability features of the tool. And this is not dependent on how much time you spend using that tool, it's more a feeling you get when using it, something that comes from intuition (which in turn comes mostly from your own personal experience, so there's not such thing as a single universal truth in this area).
True. Language preference always seems to come down to a personal thing anyway. :) As far as being a general purpose tool, make sucks. Its not even a very pretty language, but it gets the job done.
The tabbing does not bother me. At least not as much as pythons tabbing issues. A proper text editor will handle it for you anyway these days.
Touche on the Python tabbing. Still, I somehow like Python much more than I like make. Yes, I know they're very different tools, but once again I'm talking about the feeling I get by using each of them.
That makes (no pun intended??) sense.
As for not being able to do something with make that you can do with sconstruct, I highly doubt its due to any lacking features of make. Its more likely due to the level of familiarity you have with make vs python/scons. If make were as inflexible as you say, I highly doubt a build as complex as the Linux kernel would use it.
I don't recall ever saying that make is inflexible. If I did, I have to apologize, because I find make one of the most flexible tools I ever encountered. But its flexibility comes at the price of expresivity and user friendliness (or, in other words, the sheer beauty of the language :) ) IMO. A price that some people (me included) aren't willing to pay unless they absolutely have to. If we were to follow the same principle in programming, we'd probably have to use C and nothing else, since it's such a flexible language. In the end, everybody needs to find his own balance and decide on the tool he finds most suitable for his own needs and preferences. It's always good to be able to make a choice.
Make is flexible, but ugly as hell. ;) I would never use it as a general purpose thing (I don't think you even could, there are some things make can't do, like math IIRC) but it is good for what it was designed for. I am not saying that you can't or should not use other languages to do build tasks. I am however saying that using a language that was designed for it is probably better then (more efficient than?) shoehorning another language in to doing the task. The fact that the scons package had to be developed to do something that is intrinsic to make is kind of proof of this IMO.
For instance, scons seems to lack good support for directory recursion, and directory level build rules, unless you hack on it quite a bit. I once rewrote the eLua build system to factor out all the build rules into separate sconstruct files (I *HATE* long file lists with directory garbage in them), it was an immense task that could have been done extremely simply in make.
I think you can do that simpler in scons too, but I might be wrong. I do recall some quite simple scons scripts that dealt with recurssion somewhere in the internet :)
In this case I guess what I mean by simple was I would not have had to look it up in a manual to do it with make... Also, IIRC PWD/CWD issues are handled differently by scons/python vs make, which kind of confused me at first, but made sense when I started thinking of scons in terms of a single python process executing from project root, vs the way you normally do things in make.
The main reason for the frustration was that in make based build systems (usually, not always) you can just 'cd' into part of the project tree and run a make there to (re)make just that part of the tree (say if you were editing files in that directory or whatever and you wanted to run a build test). With scons, as far as I know, there is no way to replicate this behaviour. You have no choice but to run the entire build from the project root dir. Please correct me if I am wrong here!
I have in the past spent enough time as a build manager of large projects to realize that there truly is nothing as powerful as make in existence.
That's the kind of statement that I generally find "too absolute" to be reasonable, but maybe you have indeed a vast experience with _lots_ of different build systems and tools. I only tried make combined with automake/autoconf (and I completely dislike them for the same reasons I dislike make), cmake (just a quick sip), some strange system based on DOS batch files :), and that's it (with the exception of scons, obviously).
It is kind of absolute I guess. I have used scons in this project, and had exposure to it from a few other things, but never really had to *use* (maintain its use) except with eLua. I have designed some ruby modules, they sort of have their own build system, but its main purpose is to manage the construction of makefiles, so they technically use make. I have used a custom lisp based makefile management system, but again it used make on the backend. Most of the stuff I had to manage used autoconf/automake, which again is really just a makefile management system... Hmm even the buildroot based embedded stuff I had to integrate with/manage used make.... I guess I have been exposed to quite a bit of software that needed to be built, but most of it used make at some point! I have never really thought about it until now!
Actually now that I think of it, are there really any build tools out there other then scons and derivatives that *don't* use make at some point?? I can't think of any off hand, but most of the software I build is either something I manage so uses make or a make manager, or foss/gnu type software which mostly uses autoconf....
You might want to pair something with it, like automake/autoconf or rubys make file generating tools, but I have yet to find a tool as simple (and as small!) as make.
Lua ? (I know, I know, I'm just being mean here :) ). I won't argue with the "small" part, but "small" is simply not something I'm after in a build tool.
Hmm, now I do find that interesting. The point of a build tool (IMO) is to make it easy to build software. This does not necessarily mean make it easy to write the build scripts, but it does mean that a piece of software should *just build* when you unpack it. As a software developer, there has been quite a bit of things that I wanted to play with but never have because they did not compile *out of the box*. I'm not talking about having to resolve dependencies due to external libs or whatever, I mean if I have to mess with the build system to get a piece of software I just want to use to even build, then its probably not worth my time. For the most part, software that uses make as a build system *just builds*. I can't say that for anything else, because for things like scons, you would (for the most part) have to go download scons, and maybe even python, and maybe (at an extreme) build them, before you can even build the scons managed code! Thats quite a bit of work just to do a task you will more then likely only do once (build the software then install it). This is why small in a build system is good. :)
Think of all the people that don't have a fast connection that have to download a tool that may take many minutes to download and only a few to use. I would figure that being a person in a country where its hard to get hardware shipped/sourced you of all people would appreciate that. Imagine if we made people buy a hardware dongle (download a special build software) to do eLua development. Now quite a few of the people that want to do the development are in countries where buying and shipping the hardware is very difficult (slow network connection). That may be a bad analogy, but I think it fits to explain where I am coming from with my idea of build systems...
Please understand that I'm not trying to convince you that make is a bad tool, because I don't believe that. I'm just answering to your "why do you hate make" question. And I'm stating this because I don't want to start yet another religious war, although it would be a first for our mailing list :)
Hmm, a religious war around make would indeed be an odd one, esp for a first on a list. ;) Sorry if it seems like I am trying to start one, as I am not. I just never have understood the want of some to apply a large and generic tool to the job of a very specific and seldom used problem domain. Especially when there already exists a universally available and specifically designed tool for the job. Thats an issue with me, not anyone else. :)
Best,
Bogdan
PS. Hmmm ... sounds to me like you'd like to contribute a make-based build system to eLua ? :D
I could if you really wanted. I could even make it fancy with a graphical configuration tool like the Linux kernel has (in fact it would be the same tool). In one way that would be nice to have as it seperates platform configuration out of the code, but I don't think eLua is big enough to actually *need* that feature right now.
Thanks for the great debate :),
Mike
On Sat, Mar 28, 2009 at 4:09 PM, Bogdan Marinescu
<[hidden email]> wrote:
Well, personally I have a simple rule: if I keep on forgetting stuff I learn about a tool, it's not good enough for me. With make, I could never remember $@, $?, $< and other syntax stuff. Not to mention that the whole tabbing thing drives me insane. This is reminescent of the old Unix days (somebody here ever tried to modify an old sendmail.cf file ? :), and frankly (besides their unquestionable place in history) I don't think too high of them, mainly because I find them counterproductive. It's the same reason I'll never get along with perl, for example. And the list could go on :) I think we're progressing towards better tools, and although they are far from perfect, I get along with them just fine. scons is an example of such tool for me. Plus, on the more practical side, I could never do the kind of scripting I do in SConstruct with make.
Best,
BogdanOn Sat, Mar 28, 2009 at 9:49 PM, Mike Panetta
<[hidden email]> wrote:
Just a general question... Why do people hate make so much? Its extremely powerful and IMO easy(er) to use for dependency tracking build systems then any other language... Not to mention the fact that anyone that is already using GCC has gmake installed, where that can't be said about any other build tool...
Just my 0.02 currency units.
MikeOn Sat, Mar 28, 2009 at 12:07 PM, Dado Sutter
<[hidden email]> wrote:
On Thu, Mar 26, 2009 at 16:44, Arnim Littek
<[hidden email]> wrote:
Under these circumstances I'd be questioning whether scons is the right tool
for the job. Tools are not there to make life difficult, and if one doesn't
work, it is time to find another. IMHO
Under the same philosophy of "doing the most we can in Lua", I've been checking the possibility of using
Hamster.
Asko is here in the list with us and is checking what went wrong with my first try on using it.
I'm not sure if it will solve this issue though, as Hamster is also based on scons.
Best
Dado
_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev