http://elua-development.15.s1.nabble.com/Mixed-arm-and-thumb-code-tp2537643p2552481.html
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.
Interesting :) By following your logic, I'd probably come to the same conclusion I expressed in my previous message: everything but C is redundant :) since C was there from the very beginning, and everything that followed has the same functionality in the end, although the means to express it are different. Me, I _really_ like when there are many ways to do a given task, each suitable for certain kind of people. Efficiency can also be measured in more than one way, for example by factoring in the time one needs to learn a new build system, or maintenance issues. We use both make and scons where I work, and what I observed is that people that had some (spurious) bad experiences with make in the past feel more comfortable with scons. This doesn't prove much, but is consistent with my views.
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'm not sure about this. I know you can do "scons -C" just like you do "make -C", so maybe scons has support for what you want if you use multiple SConstruct files. But I didn't test this.
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!
In software, history dies hard :) which has both good and bad parts. And, from what I could gather, most "hardcore" programmers are generally reluctant to change. I'm no exception; this week we talked about the new C++ standard proposal at work, and I was completely outraged by some of its new parts, until I started to think about them and realized that most of them make sense. Why would build systems be different? :)
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....
I don't know of any.
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.
Well, thanks for this. It seems that I was so focused on how much I dislike make that I forgot to think from the perspective of the end user when it comes to building. This is indeed a very good argument towards make, and one of the reasons it is still so popular. Maybe it's not fair, but so is life :)
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. :)
You don't have to compile scons, fortunately, but everything else is true.
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...
That makes sense, although it's more of an exceptional case; I would imagine that if you have enough bandwidth to download eLua, you could spare some for python/scons too. If you want to do serious development and you don't have access at least to a medium quality Internet connection, your developer life won't be easy anyway. Sad, but true.
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. :)
It might be an issue with you, yes :) Once again, try to apply your own logic to programming languages in general, and see where it takes you. And I wouldn't consider a build system something "seldom used"; quite on the contrary, a build system is present everywhere but in the most trivial projects.
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.
So how do we convince you to really want it? :) Cause really, all this discussion had the (good) side effect of convincing me that a make-based build system is a good thing, at least as an alternative (although having a project with two different build systems to choose from seems just plain weird). In particular, I'm very curious how you'll manage to duplicate the non-build-specific parts in SConstruct using make, like all the platform/CPU mappings, the filesystem/board mapping and so on.
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.
It might not need it, but it's surely on the top 5 of our "TODO" list, and we'd very much like to have it as soon as possible. It's the kind of thing that makes a project look really professional (see for example Ethernut) and it saves you from reading all the documentation about the configuration parameters (although I put a LOT of effort into writing that, so part of me doesn't really want this to happen :D Kidding, of course).
Thanks for the great debate :),
You too!
Best,
Bogdan
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
_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev