On 19.02.2015 10:59, Ithamar Adema wrote:
In all honesty, I still think that starting a recent brach and reusing the Jam build system, maybe even hooking into the *_build target somehow, might be the best way to go.... Our "little" project (Haiku) has become to complex to really sensibly duplicate the whole build system IMHO... Not to mention the maintenance nightmare of keeping that up to date...
FWIW, if the plan is to port a fairly recent Haiku, I'd probably rather start from the scratch with recent Haiku (a late pre package management version to save some complexity). Remove kernel, kernel add-ons, etc., clean out libroot so that you're left with Haiku specific code and stubs for syscalls. Then get things building and finally flesh out the stubs. For the last steps I'd borrow solutions/code from Cosmoe (and Haiku's build platform abstraction), if they make sense.
The main reason why I don't think it would be a good idea to first get Cosmoe working is that its exact state seems to be fairly unknown. Getting a diff against the Haiku it was forked off of would help a lot, but it would still be difficult to determine what easter egg problems have been left in the code. E.g. I had a quick look how the entry_ref to path problem was solved and... it wasn't. The code [1] will just construct a bogus path and client code will fail in weird ways.
CU, Ingo[1] https://github.com/Ithamar/cosmoe/blob/master/src/kits/storage/kernel_interface.POSIX.cpp#L931
