New build process / libosmocore

[Harald Welte]

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 at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)