Hi!
The following patches split libosmocore in two libraries, the new libosmo-gsm, which contains GSM-specific functions, and libosmocore, which contains generic functions (like talloc, msgb, select, logging, ...).
In case that you're OK with them, you have to apply them in the following way:
1) First, make a copy of libosmocore.git to libosmo-gsm.git. This is done to avoid losing the history in the new libosmo-gsm.git library.
$ cp -r libosmocore.git libosmo-gsm.git
2) Apply the patch that removes the GSM-specific features to libosmocore.git (see [PATCH 1/2])
2) Apply the patch that removes the non-GSM features to libosmo-gsm.git (see [PATCH 2/2])
After these patches, I'll send two patches for openbsc and osmocore-bb to make them use the new libosmo-gsm.
Let me know what you think with this proposal.
Hi,
- First, make a copy of libosmocore.git to libosmo-gsm.git. This is
done to avoid losing the history in the new libosmo-gsm.git library.
Can't this be made with git filter-branch somehow ?
Just create a new tree that only has the history of all the gsm stuff and nothing of the rest.
After these patches, I'll send two patches for openbsc and osmocore-bb to make them use the new libosmo-gsm.
I guess we'll need to use git-submodule for this as well in osmocom-bb.
Cheers,
Sylvain
PS: Haven't looked at the actual patches yet, just preliminary comments.
On 17/03/11 22:08, Sylvain Munaut wrote:
- First, make a copy of libosmocore.git to libosmo-gsm.git. This is
done to avoid losing the history in the new libosmo-gsm.git library.
Can't this be made with git filter-branch somehow ?
Just create a new tree that only has the history of all the gsm stuff and nothing of the rest.
I'm not a git master, I'll check the docs to see if this is possible.
After these patches, I'll send two patches for openbsc and osmocore-bb to make them use the new libosmo-gsm.
I guess we'll need to use git-submodule for this as well in osmocom-bb.
Yes, AFAICS we'll have to use git-subtree like with libosmocore.
PS: Haven't looked at the actual patches yet, just preliminary comments.
Thanks for this preliminary review!
On Thu, Mar 17, 2011 at 10:08:47PM +0100, Sylvain Munaut wrote:
Hi,
- First, make a copy of libosmocore.git to libosmo-gsm.git. This is
done to avoid losing the history in the new libosmo-gsm.git library.
Can't this be made with git filter-branch somehow ?
I think we might just build libosmo-gsm as part of the libosmocore.git repository, similar to what we do for libosmovty. But this may be a matter of personal taste ;)
What do others think about it? I think splitting the include paths and the .so file names makes users (i.e. the application programs) aware that it is two libraries.
Splitting the git repositories doesn'nt really buy us anything apart from yet another git checkout/update/configure/make/... that needs to be executed.
If at some future point we want to split the repositories, it will not incur any changes to the application programs like openbsc, as they already check for two different pkgconfig etc.
Hi Harald,
On 18/03/11 12:58, Harald Welte wrote:
On Thu, Mar 17, 2011 at 10:08:47PM +0100, Sylvain Munaut wrote:
- First, make a copy of libosmocore.git to libosmo-gsm.git. This is
done to avoid losing the history in the new libosmo-gsm.git library.
Can't this be made with git filter-branch somehow ?
I think we might just build libosmo-gsm as part of the libosmocore.git repository, similar to what we do for libosmovty. But this may be a matter of personal taste ;)
What do others think about it? I think splitting the include paths and the .so file names makes users (i.e. the application programs) aware that it is two libraries.
Splitting the git repositories doesn'nt really buy us anything apart from yet another git checkout/update/configure/make/... that needs to be executed.
The only compelling argument that I can find to support the split are releases. You can make release of the two libraries independently, in case that this is one critical bug in one of the part.
However, I agree that we can do this in the future.
If at some future point we want to split the repositories, it will not incur any changes to the application programs like openbsc, as they already check for two different pkgconfig etc.
I'll resend the patches with this new approach, putting all GSM-specific stuff under a directory called libgsm inside libosmocore.
I can send patches to rename vty to libvty, and codec to libcodec (for consistency with the naming approach in openbsc) if you like the idea.
Hi Pablo,
On Sat, Mar 19, 2011 at 08:44:29PM +0100, Pablo Neira Ayuso wrote:
If at some future point we want to split the repositories, it will not incur any changes to the application programs like openbsc, as they already check for two different pkgconfig etc.
I'll resend the patches with this new approach, putting all GSM-specific stuff under a directory called libgsm inside libosmocore.
ok, thanks
I can send patches to rename vty to libvty, and codec to libcodec (for consistency with the naming approach in openbsc) if you like the idea.
I think the subdirectory-naming doesn't really matter that much in libosmocore, in OpenBSC I made it simply to distinguish between 'libbsc' and 'osmo-bsc' which both have BSC in the name.
Thanks in advance, Haradl