We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Apache OpenOffice Buildsystem

00:00

Formal Metadata

Title
Apache OpenOffice Buildsystem
Alternative Title
Openoffice Build system: A walk through building OpenOffice
Title of Series
Number of Parts
490
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
This talk will be about the OpenOffice Build system. We will talk about how it works today's, issues with it. And the talk will highlight current development in this field plus where it might moves in the future. (plans of development) Sheduled length will be 20 min +question Currently the build system is a mixture of dmake, gmake, ant and other tools. After a short going through I like to describe the vision we have for the future build system we are working towards.
33
35
Thumbnail
23:38
52
Thumbnail
30:38
53
Thumbnail
16:18
65
71
Thumbnail
14:24
72
Thumbnail
18:02
75
Thumbnail
19:35
101
Thumbnail
12:59
106
123
Thumbnail
25:58
146
Thumbnail
47:36
157
Thumbnail
51:32
166
172
Thumbnail
22:49
182
Thumbnail
25:44
186
Thumbnail
40:18
190
195
225
Thumbnail
23:41
273
281
284
Thumbnail
09:08
285
289
Thumbnail
26:03
290
297
Thumbnail
19:29
328
Thumbnail
24:11
379
Thumbnail
20:10
385
Thumbnail
28:37
393
Thumbnail
09:10
430
438
Integrated development environmentBuildingInformationElectronic program guidePhase transitionSoftware development kitJava appletSoftware testingScripting languageDefault (computer science)Software frameworkSelf-organizationComputer configurationConfiguration spaceMultiplication signPhysical systemOffice suiteTextsystemBitProjective planeOpen setWikiSoftware developerDefault (computer science)Software testingBuildingIntegrated development environmentJava appletLink (knot theory)Software frameworkComputer configurationFirmwareRevision controlRobotConfiguration spaceLibrary (computing)WebsiteLevel (video gaming)WindowDistribution (mathematics)Web pageAxiom of choiceOrder (biology)CodeOpen sourcePresentation of a groupException handlingAuthorizationScripting languageMetropolitan area networkDifferent (Kate Ryan album)InformationBinary filePhase transition19 (number)Traffic reportingText editorMappingSound effectProcess (computing)Staff (military)Instance (computer science)FamilyThomas BayesOptical disc driveService (economics)Automatic differentiationElement (mathematics)Computer animation
WikiAbelian categoryExecution unitBuildingComputer configurationIntegrated development environmentShared memoryGroup actionSound effectSqueeze theoremStaff (military)Optical disc drivePerspective (visual)Physical systemMereologyMultiplication signAreaFlow separationFrequencyArithmetic meanCodecSpacetimeBitFormal languageHuman migrationCategory of beingIntegrated development environmentWikiFreewareAxiom of choiceComputer animation
WikiAbelian categoryBuildingComputer configurationIntegrated development environmentBuildingUnit testingSymbol tableGroup actionComputer clusterCodecCuboidError messageMoving averageSoftware testingComputer configurationInstallation artTunisAreaOffice suitePhysical systemLibrary (computing)Functional (mathematics)Latent heatModule (mathematics)PlastikkarteExtension (kinesiology)Category of beingStandard deviationWindowUtility softwareComputer animation
BuildingParallel portIntegrated development environmentModule (mathematics)Physical systemModule (mathematics)Process (computing)2 (number)Staff (military)CodeOffice suiteEmailData miningElectronic mailing listAsynchronous Transfer ModeBootstrap aggregatingArrow of timeSoftware crackingMultiplication signBitOpen setBuildingThread (computing)RobotVirtual machineCoprocessorComputer animation
Module (mathematics)BuildingHydraulic jumpPhysical systemParallel portIntegrated development environmentModul <Datentyp>GezeitenkraftPrincipal idealArmMathematicsOrder (biology)Interface (computing)Module (mathematics)BuildingSoftware developerComputer animation
Module (mathematics)Parallel portBuildingIntegrated development environmentPhysical systemProcess (computing)Endliche ModelltheorieModule (mathematics)BuildingIntegrated development environmentComputer animation
Electric currentPhysical systemIntegrated development environmentScripting languageBuildingDisintegrationBuildingPhysical systemProcess (computing)Integrated development environmentJava appletScripting languageLatent heatDistribution (mathematics)Module (mathematics)Slide ruleConfiguration spaceMixture modelOcean currentOffice suiteWeightPerspective (visual)Computer configurationMereologyEmailMoment (mathematics)Metropolitan area networkCodeSign (mathematics)Computer animation
FacebookPoint cloudOpen source
Transcript: English(auto-generated)
Time to start, yeah? Yeah, welcome to our developers' room for office systems. I don't know the true name, but... Yeah, maybe it's Open Document Editors.
Yeah, Open Document Editors, yeah? So, and I will have a small talk about building an open office, our build system, how it works, and so on. The reason for it is I get asked on the recruitment channels often,
how do I build open, or I want to contribute, and then I say, okay, build open office, and then I don't get an answer. So I hope that with this talk, I can help people a little bit more to get over this hurdle.
Yeah. So my name is Peter, and I'm usually using the nickname Petco. I joined in 2016 the Open Office project from Apache, and I was the chairman 2018 and 2019.
Yeah, that's what you need to know about me and what I do in the project or what I did so far in the project. Yeah. Okay, like I said, the goal of this talk, it's, I won't give you an overview.
I do not want to go really deep inside depth. I will not go so much into the differences between Windows, Mac. So it's more about principles, what you need to know, and the understanding. Yeah? And I will talk a little bit
what I picked up, where we were going with the build system, how it's changing. We work on this from time to time, and, yeah. So if anyone is interested in building open office,
we have written two guides, one with general information, where we explain a lot what and how these options is, what does it mean, and so on, central stem things. And if you have an OS
and you want specifically built on for one, for your system, then we have an OS page where you, on detail, get explained from Windows or Linux, even break down among certain distributions. I can only recommend,
if you download the presentation, use the links. The presentation is only in helper and we're giving you some guidance, you know? So when we build open office, we have, let's say, different phases, you know?
Where we built, which you have to follow in order to get a successful build. First, you set up your environment. That means you prepare, you have to install the dependencies that the building environment needs to get working.
Then we have to do a configure that the build system knows what do you want to build. The third is bootstrapping. Then we pull in the dependencies that we need for building the code.
Even if you pick the choice that you go on system libraries, where you have probably to do some adjustments, but our build environment is set up so it's generally working.
So you have, so we pull in all dependencies and we provide all the dependencies from our resources, ourselves. So if you build open office plain,
then you will provide all the dependencies in the right versions that there is. If you want to use the system libraries, you will have to tweak around, probably. And, yeah, and the last thing is to build open office, you know? Building commands and so on.
So build environment needs a working PAL version and for the Java stuff, and Java, of course, we have Gperf for, Google Perf for performance test.
You need this UNU WinRag DLL for building. At least I did not know how to circumvent this. Did you? Yeah. Okay, I get all those complaints from the,
but maybe if you say without SDK, then it will not, you will not be a request to set it up. If you build on Windows, you will need additional tools,
the Mozilla build tool, for example, and the Microsoft SDK. On Mac, you will also need some special, the SDK firmware for Mac. I'm not sure which version thought. In doubt, if you have questions when you're trying it, ask on the dev there. We help you look it up.
You get the answers you need, you know? So if you have installed everything and you're prepared to build, then you can go to the next level and you have to know a little bit how, where we store some stuff.
So in the X libraries and in the X sources, we have, we will store our dependencies, yeah? So the, the instset.oo native folder
is where we build OpenOffice. This is the home folder of the build. There we will start the build scripts from and it will always also provide a default to build in this folder, yeah? And there's a test,
where the test framework is. I cannot, you know, I just took this test stuff from the website so I don't know exactly how this stuff works. Yeah, then we have set up our environment.
We know where the dependencies goes and so on. And then we want to configure our system, yeah? So we use auto-config, auto-conf, and then configure for doing this, like in most,
like in most Linux or open source projects. But for the starters, you need to, to say some, some, you have to switch some, some switches, you have to give that. And my recommendation is you can go on the C Wiki
where we have layout with some examples where you can start or you can use the build bots. We have some build bots that run every day and you can start with their configuration and with their links and so on. We will look then what's,
we will take a short look what the important switch is and there are some more and you can have the look. For example, this is most, the most central one.
We have, we have loranda-autoconf, then you start with .configure, then you have the first switch you will always need. With dmake, we still use the old dmake system in parts.
We are in the migration, we are running away from dmake to the remake and if the migration is done as far as I know, it will use automatically. So, but we still need to use this. When you, when you pass the URL,
then you can, then it will, I don't know, I think in the bootstrap, it will download dmake, it will be built automatically and you have not, you need not to do any extra stuff. The EPM is the second dependency
for the build environment which we need. You can also install this separately and have it, and just pass the URL where it can be directly found.
Here, it will be downloaded and built on the EPM we need for packaging. So, if you build depth files, RPMs and so on, this will be done by this package. Then, with LAN, you define which languages you want.
These languages are copied from the buildbots. So, you have a short choice. If you do it for yourself, then you will, you will maybe reduce it or, so.
And then you have some switches like wiki publisher, wearables, category B, enable OpenGL, enable DBOS. Without JUnit and enable bundled directions, these are still a bit what will be built, how it will be built.
For example, enable category B. This is a license issue. If you, or not issue, but it's a licensing stuff. So, OpenOffice is built quite modular, and the core, it's an APL2,
but which is from Apache perspective, a category R license, also other free license like the,
no, I forgot. Like other similar license to the Apache license, there will be also category R and other licenses like the Mozilla license is counted like category B. So, if a module of a third-party extension
is made in, is published with Mozilla, this is the Mozilla license. For example, you need this enable category B so it will be built with the build. You're going to do. Enable OpenGL will enable the OpenGL stuff.
On Windows, you have also the option to use DirectX if you have the SD card available for it.
DBOS is something Linux specific and so on. I recommend to use this vendor and then just write something so it's not confused as an official build. If you do it as an official build, you will probably get into some issues
if the PMC looks at it. If you build for yourself, you can give with the option or with the switch, with package formats, you can give the, you can configure what packages it will be installed,
if it's ABRBM, RPM, DEB or whatever. If you use installed, it will be, it will be roll out in the build folder and you can directly use it for your tests. The last two are enabled debug util and enable symbols
that will help you in the debugging. You can then attach it to GDB or you get a search error if you open up the Windows. The last thing is you can deactivate modules
like without JUnit will deactivate the JUnit testing. Without STLport, you will, you will disable a specific module
that this STLport especially will, is about some basic standard library functionality and it's, and this one is, I put it in there because we usually build without STLport, the modules,
so maybe for starters, you will want to do this also or you want to use this for, you want to use this option. If you use this option as it is given here, at least on Linux, it will build quite nicely
and you will get a debug-able build of OpenOffice. So when we have configured our system, we do a bootstrap in between. The bootstrap is only downloading the dependencies we want to build. The command for building OpenOffice
is build all p8, for example, minus p8, slash slash, or dash dash, and dash p8. For example, and what does it mean? It means we want to build everything
with eight parallel modules built and with eight threads per module. So, yeah, this is pretty much,
with p8 and p8, we have rather bad experience. I think it's maybe better to use something like p2 and have here something p8, depending on your processors. You have to experiment with it a little bit
because OpenOffice still needs a lot of time. Build bots need something like, I don't know, six to 20 hours, yeah? Was it, right, something like that? Build is quick.
Build is quick, okay. I need something around an hour, maybe, on my machine. Yeah, so what does it mean with this p8? I have some, maybe some graphics,
some small graphics to make it more clear, maybe. We look at the first pm. We have our modules, yeah? If we use p1, it will build one module after another. If we have build with p2, it will start with the first module and then depending on the dependency setup,
it will start to go ready for two or more stuff. It will open up more parallel buildings, yeah? So if you have too much parallel modules to be built,
we have some dependency lacks, I think. You will maybe find out that we want to build module three but it has a dependency to module four and module four is not built and so the build will stop with an error.
Best is if you come across these things, ask about on the dev mailing list and we will look into it and we will help to fix it. If we go to the p, if you go to the second switch,
if you build one module, then we open up more one-on-one threads and we build this code stuff in parallel. You can also think this will be passed, the second one will be passed to dmake and gmake
so they work in parallel and they work faster. If we do our builds and it stops and we fix something, then it breaks and we fix it and we want to continue there or we have to, we clean something up.
Then we don't want to start over. So we can continue where we have stopped or in the module where we did our changes, we can set up at this place and restart the build
and there's two ways you can do the build. The first one is we talk of compatible builds and we talk of incompatible builds. So for example, we have module one, we have module two,
we have module three, we build all three or we build, we started to build all three and then we do a change in module two. So then we want to set up again on module two and the wise thing is to build then again module three.
If we build module three or we set, we would give then the build command build from module two. And the build will then know, okay, I want to build also module three.
I will go in depth just to have the principle. And in compatible builds, we already know module three will not be affected. We are sure as a developer that this module, that the change in module two will not affect module three or anything that comes after it.
So we only build module two, which will be much quicker. But well, if there's something changing in the interfaces or something, then you have an issue that might be difficult to debug.
So the recommendation is definitely, if you have no idea whatsoever, then do incompatible builds, build everything from the place where you quit and then you're safe.
The build command is done in the instset oo-native. Then the build environment will always know that you want to continue after the module you have changed is done. It will automatically know which dependencies after that
has to be rebuilt. For that, we need to clean the build that has already been done. This is done with the command build from module two minus minus prepare, yeah?
But since we also use gmake and gmake will not respond, will not be cleaned with the minus minus prepare, you need also to set up build minus minus from module two
and then minus job and then make clean, make clean debug equals T minus ignore. This will be safe for you. Then you have really cleaned your build environment and you can really start over with build from module two, yeah?
This is something you have to keep in mind for this and quick look on the... So and if you do compatible builds,
you go into the module name and just clean in the module, yeah? If it's a module that is based on gmake, you can just pass a make clean and then you're done and then you can start with build from module two.
Okay. Last slide. As we have seen, the current build environment is at the center of its build, it's a Perl.
So the build command is a Perl script. We use a mixture of dmake and gmake. I think it's, I don't know, I'm not very sure, but I think around 60 to 80% of the modules are already on gmake
and we use and for Java stuff or Java code. In the future, there's some, there's quite an agreement that we will move away from the build Perl script. The preference is to only use the GNU make.
So you have the standard make, make install and stuff. We will continue to use and. Our GNU make configuration is set up in the way if there is Java in the module,
then make will automatically fire up and build Java. So this is for building perspective, it's the end is really on the floor,
but maybe if the GNU make, if the build Pl will not replace the, if you cannot replace build Pl with the GNU make, then maybe end will become an option. There's also the wish to use Python or Scon,
but it's not so preferred. So let's put it like this. And yeah, in future, we will only use gmake, we will drop dmake if we manage to recreate the last modules.
To gmake, we will continue to use end. And this is my personal wish, that we someday can use an EDE, I don't know, Eclipse NetBeans or something to develop OpenOffice further.
So yeah, thank you for your attention and for this quick run through the OpenOffice build system and environment.
We have, I think, one minute for questions. Yes? So currently, there's, I think, no specific support
for specific distributions. I don't know. You do Debian specific builds, right?
Oh, you mean the signing the build code? In the current builds or current releases,
we did not do this. We have a process in place or we have people who are looked into it and with the next release, we will start to sign our builds for Mac. And I'm not sure, we try for Windows, yeah?
But this is, I think, at the moment, a manual process and we have to make our experience until, and we will see if we get that, how we can get the process then smaller. So we start with a separate manual process and then go to, and then see where it takes us.
I hope it answered your question. Anything more? Okay, thank you for your audience.