search

jdetter / Chronos

The Chronos kernel
GNU General Public License v3.0
9 stars 1 forks source link

Incorportate a build configuration system. #7

Open spwilson2 opened 8 years ago

spwilson2 commented 8 years ago

To consider:

I'll also update this first comment with any other suggestions to consider and leave discussion to comments.

spwilson2 commented 8 years ago

Right now I'd vote for SCons since it definitely looks easier to pick up than CMake. I also like the fact that it's using actual python instead of a made up language like CMake. But to be thorough I've read that SCons is slightly slower than CMake (although I don't realistically see that being an issue with how small our source is). It should still be faster than our Make system though, since it can compile at multiple levels/directories at the same time.

kconfig probably isn't worth the work needed to port. And I'm not sure how complicated it is to work with since there likely isn't all that much documentation on it.

autotools reviews are aheh. I don't think this is worth considering at all. The only benefit over others is that many GNU projects use it.

jdetter commented 8 years ago

What build system do you use at work?

spwilson2 commented 8 years ago

Well coreboot uses its version of kconfig since they started out by trying to keep Linux like standards for bios development. I've never had to do much in coreboot though so I don't know how difficult it is to actually work with.

spwilson2 commented 8 years ago

Probably can't talk about the UEFI build system, but it's not worth looking into :3

jdetter commented 8 years ago

I would absolutely agree that autotools is realistically not going to happen. Although it is the standard for all GNU tools it is impossible to use and maintain.

I do like CMake though. It's not as versatile as autoconf/automake but I think as a build system it's pretty good and widely used.

I've never heard of SCons or kconfig but I will definitely look into them and try to make some sort of opinion about them lol.

spwilson2 commented 8 years ago

The basis of UEFI build. But I still would say it's not worth looking into.

spwilson2 commented 8 years ago

We're going with scons for the build because I like python. :dango: We'll need to discuss how we're going to actually set debug mode and such once I get the project building.

jdetter commented 8 years ago

ok, let me know how it goes!

jdetter commented 8 years ago

One thing I just realized about this, is that we won't be able to build Chronos inside of a Chronos system if we use Python. We don't have a python port right now.

spwilson2 commented 8 years ago

Hmm, after looking at the build for a while now, I think it would be possible to fix up a lot of it and go back to a non-recursive make build if make is actually supported.

spwilson2 commented 8 years ago

If that were the case, we probably would go the kconfig route, which I think is basically a c script that reads .configs and then defines certain variables in kconfig.h which is auto included to all sources.

jdetter commented 8 years ago

I mean we can keep going with scons, we just need a python port

spwilson2 commented 7 years ago

After a few iterations, I think I've finally settled somewhat on an API for the build. I'm writing up a spec for it right now. It's based off the Kbuild/Kconfig system of the linux kernel but still is going to use SCons. Infact, the Kconfig portion will be exactly the same... A repo containing the spec and a simpler (but similar) file heirarchy for prototyping will be at https://github.com/spwilson2/Sbuild.

Sorry this is taking so long and so many iterations, a lot of thought needed to go into this but I've not really had any time to sit down and plug away at it. I'm thinking this version should be fairly extensible since it's related to Kbuild. Even better, it should be possible to port back to make if we ever decide Scons isn't for us. (I still greatly prefer Scons since I would have no clue how to fix a bug in Kbuild if it broke).

Edit: The spec is both for my design process, and after completing it, should probably be rewritten a bit for anyone working with the build.

Edit2: Since this essentially means I'm rolling our own build framework from SCons, it might take a good while longer.

jdetter commented 7 years ago

Thanks for all of the hard work! I'm sure whatever you have is better than what's there now. If it uses Python that's fine, we can just add a python port, it shouldn't be that hard.