New build process / libosmocore

Hi! After much delibeation I have devoted today to 'fix' the way how we build the project and how things depend on each other. We have a couple of challenges: 1) there is (and should be!) a lot of infrastructure code sharing between OpenBSC and OsmocomBB Layer2/3. I'm referring to stuff like linuxlist.h, msgb.[hc], bitvec.[hc], the various GSM protocol header files, timers, etc. 2) we want to do the layer2/layer3 development on the PC, while the layer1 resides on the target phone. However, the code should be API compatible and just compile when we later decide to move (parts of) it into the phone. 3) there is already some code like "msgb" which is used both in layer2(PC) and the phone. 4) I don't want to have too many build dependencies as it makes it unneccesarily difficult to get started with the project. So everything should build from the git tree we provide 5) we dislike the idea of code duplication or copy+paste. This means that we need to build some stuff like libosmocore twice; for the host PC and for ARM The solution looks like this: * libosmocore lives in its own git://git.osmocom.org/libosmocore.git repository. This is where we make changes to it. * libosmocore is 'squashed' into the osmocom-bb.git repository by means of git-subtree[1] to make sure challenge '4' is fulfilled. This is transparent to the user who clones our tree. However, if you want to make changes, please ensure that a commit either only touches files within src/shared/libosmocore or outside of that directory. Mixed commits will require manual action and are tiresome. * everything is built using autotools, except for the 'firmware' (what used to be hello_world) * there's now a top-level Makefile, which * builds libosmocore for the host * builds libosmocore for the target * builds osmocon for the host * builds layer2 for the host * builds the target firmware I understand that this process is quite a bit more complex than what we used to have, but it is the best option that I could come up with. I particularly hope that I didn't do something stupid which would break Cygwin builds... we want to keep Dieter as productive as he currently is, after all :) Regards, Harald [1] git://github.com/apenwarr/git-subtree.git -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)