[openbeos-build-team] Re: Building on linux

  • From: "Ithamar R. Adema" <ithamar@xxxxxxxxxx>
  • To: <openbeos-build-team@xxxxxxxxxxxxx>
  • Date: Sun, 30 Jun 2002 02:42:22 +0200

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
> 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?



Other related posts: