New build process / libosmocore
laforge at gnumonks.org
Sat Feb 20 22:41:35 UTC 2010
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
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 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 :)
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
More information about the baseband-devel