#8730: Improve the build system for building on Haiku ----------------------------+---------------------------- Reporter: mmadia | Owner: mmadia Type: enhancement | Status: in-progress Priority: normal | Milestone: R1 Component: Build System | Version: R1/Development Resolution: | Keywords: Blocked By: | Blocking: Has a Patch: 0 | Platform: All ----------------------------+---------------------------- Comment (by bonefish): Replying to [comment:13 mmadia]: > As a quick summary, 18 headers are done out of 123 (judging by {{{ find . -type f | wc -l }}} in headers/build/[config, os, posix]). > For {{{ jam -q libroot_build.so }}}, src/build/libroot/atomic.cpp and src/build/libroot/byterorder.cpp compile and currently fails on errors.cpp. [...] > And that brings us to [http://cgit.haiku- os.org/haiku/tree/src/build/libroot/errors.cpp errors.cpp] [...] > How should we proceed? That is really not the problematic case. The libroot_build implementations should be able to use the STL just fine. I doubt the errors have anything to do with that. The obvious problems are: * The concerned target_* headers must be included, too. * The `ADD_ERROR()` macro needs to be adjusted -- it uses the prefix `HAIKU_` for the Haiku constants. I think it has to work differently, though. We completely wrap all functionality the client code uses, so for instance `_haiku_build_strerror()` will only see the error codes we define. Consequently Haiku's `strerror()` code can be copied (with the prefixes, of course). `_haiku_build_errnop()` can simply return the pointer to a static int variable (let's call it `sErrno`). We still need the mapping between Haiku and build platform error codes, but at different times, namely when functions that return error codes or set or read `errno` are invoked. In pseudo code this would work like: {{{ _haiku_build_ssize_t _haiku_build_write(int fd, const void* buffer, size_t count) { ssize_t written = write(...); if (written < 0) sErrno = convert_to_haiku_error(errno); return written; } }}} Where `convert_to_haiku_error()` would be named something suitable with a prefix, `sErrno` wouldn't be accessible outside of "errors.cpp", so there needs to be a setter function for that purpose (since that will be common, there should be one that directly sets from `errno`). -- Ticket URL: <http://dev.haiku-os.org/ticket/8730#comment:15> Haiku <http://dev.haiku-os.org> Haiku - the operating system.