gbuild: How to setup a repository
This is the third post in a short series of blog posts about the new GNU make based build system that will soon be integrated into the DEV300 codeline. It is covering how to use the multi repository support of gbuild.
Welcome back to the little blog series about the new GNU make build system. After having covered the setup of a module in the gbuild system in the last post, this one will be about how repositories are setup with gbuild. A repository in gbuild is a directory where source files are found. While OpenOffice.org currently has every source file in one big repository, gbuild supports to have multiple repositories and will find a file in any of those.
Making repositories known to gbuild
gbuild needs to be told about the repositories it should look for source files. This is done with the variable gb_REPOS which contains a whitespace separated list of source directories. For backwards compatibility, if gb_REPOS is not set, it defaults to $(SOLARSRC) for now (we might get rid of that one day and set gb_REPOS in ./configure along with SOLARSRC).
Setting up a repository for gbuild
Three files need to be present in the root of a gbuild repository:
- Repository.mk
- RepositoryFixes.mk
- and Module_*.mk
In Repository.mk we define some things that need to be globally known for the build. The first thing that needs to be globally set is a variable name for this repository, so that we can refer to it -- for example when defining include paths. This is done by a statement like this:
>
$(eval $(call gb_Helper_register_repository,SRCDIR))
Because of this statement the OpenOffice.org source repository can be referenced as $(SRCDIR) when defining include paths. Other repositories should obviously use a different variable name for their directory.
In addition, we need to declare the naming scheme and the layer that libraries and executables end up in the final product. With the statement:
$(eval $(call gb_Helper_register_libraries,OOOLIBS, [...] fwk [...] sw [...] ))
We register the libraries "fwk" and "sw" to be "OOOLIBS". What this means exactly depends on the platform, but on Linux 64-Bit for example it means that the libraries are named "libfwklx.so" and "libswlx.so" and will end up in the OpenOffice.org layer of the product. This information needs to be declared globally in the repository and can not be simply declared in the local files in the modules like framework/Library_fwk.mk : When one does a partial build (only one module, e.g. sw) that information is still needed, because the filenames of the linked-against libraries need to be known. On OSX, additionally the exact location of the linked-against library (and thus its layer) needs to be known at linktime.
The second file RepositoryFixes.mk is to fix for those cases where developers got too creative for their own good and followed a naming scheme only mostly: naming it slightly different on one platform, for example. When gbuild starts up, it parses the Repository.mk in each repository. Then it loads the platform defaults and assigns the names and layers according to it. After that the RepositoryFixes.mk file in each repository gets parsed and can fix around "special cases". It should contain all the hacks that work around things that break the usual systematics.
The final file is the Module_*.mk. In the case of the OpenOffice.org repository this is the Module_ooo.mk file. When everything is migrated to gbuild, one will not build module-by-module, but with one make process. This make process will finally, after parsing all other setup code, go into each repository it find in gb_REPOS and include the one Module_*.mk file it finds there. After parsing those module files, the modules in each of those are added as dependencies to the all target -- they need to be built and it turn ensure all modules that are part of it to be built. Gbuild modules can include other modules (yes, you can build "module trees" of arbitrary depth). Module_ooo.mk is just a module that includes all migrated modules.
Ok, enough already of this dry and rather boring topic. The next post will be about eyecandy for developers.(This is a very raw mirror of the original blog post made to blogs.sun.com on 23 Nov 2010. As per http://web.archive.org/web/2009062714425
This was originally published at 2011-07-26 10:16:00/2011-07-26 08:16:40 on livejournal.