Wow, it is getting hot in here :-) Just some reactions, sorry for quoting bits and pieces, but this was the easiest way to clear some stuff up :) From: "David Reid" <dreid@xxxxxxxxxxxx> > I personally think we'll suffer if we have a tree that can only be built on > beos. Suffer? How do you mean? I think it would be appropriate to include an explanation :-) >Anyway, we can add rules tro determine the OS and have things switched >on/off accordingly. I couldn't see how to do it which is why i didn't add >anything more than I did. This is not needed. There are several good and useful ways to check this, just take a look at the docs or the Jambase file. $(BEOS) and $(UNIX), $(WIN32), etc if I'm not mistaken :) From: "Ryan Leavengood" <leavengood@xxxxxxxxxxxx> >I just think getting the hold build environment working on Linux is >akin to just using Linux as the kernel. I really thought we were >keeping away from that, unlike BlueEyedOS and Cosmoe. I mean, if you >can build the whole tree on Linux, why not just run everything there as >well? Or will it be the case that you can compile but not test on >Linux? What use is that? Hmmm I don't really agree with this. Compiling the OpenBeOS kernel on Linux and then using VMWare on Linux to test the kernel (and possibly user-space apps) could prove very useful. Also, compiling on a different machine then the one it's going to run on (called cross-compiling) is a very common thing, and what we do is bootstrapping, so the starting point shouldn't matter (it's the first step up the ladder, the interesting part are the next ones :)) Supporting Linux in our build system is just a matter of deciding whether the costs (both in implementation as in maintenance) is going to be worth the gain (hours or maybe even extra people contributing to the OpenBeOS _code_). It is that simple IMHO. > Flexibility is good yes, but it is not something you can just hack > together in a few minutes. We need to think about it and build a good > solution. Agreed. I think we should think very carefully what we want to do with the build system and what not. As of currently, the included bootfs will probably be phased out as soon as we've got BFS or so running from OpenBeOS, and if so, a lot of the "tricks" (might also be called hacks) in the Jamfile/Jamrules changes can be cleared up anyway. I think it might be an idea to create a rough ouline what we want out of the build system, so we can design it correctly, instead ending up with a big bag of hacks and if()s. We want to keep it all maintainable, I think? Regards, Ithamar.