Re: [dev] Re: Build Comments
Bjoern Michaelsen wrote: Ok, I will remove the references from to gpc from the Building Guide for current releases. However, the directory external/gpc needs to be removed and configure needs to get rid of related options. Is there a bug for this already or do I need to open a new one? Hi Bjoern, heh, well, beforehand, better check whether indeed tools/source/generic/poly2.cxx does not get HAVE_GPC_H defined for the setsolar env. I'm not aware of an existing bug for the cleanup, please also dump the parts in poly2.cxx then. Cheers, -- Thorsten signature.asc Description: Digital signature
[dev] Re: Build Comments
Thorsten Behrens thb at openoffice.org writes: all distros I know of are using the non-gpc clipper since ages, I'm not aware of any regressions there. Also, if my memory does not fail me, Hamburg switched to non-gpc for 3.0, at least I don't find any traces of WITH_GPC in solenv anymore. Ok, I will remove the references from to gpc from the Building Guide for current releases. However, the directory external/gpc needs to be removed and configure needs to get rid of related options. Is there a bug for this already or do I need to open a new one? Best Regards, Bjoern Michaelsen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: Build Comments
Terrence Miller wrote: If OOo wants to be able to reproduce builds, we will need to have a local snapshot of any package listed as a build requirement. The idea is that QA person should be be able to take a blank machine, a Linux install CD, and a CD containning a milestone and after doing an install and loading the second CD do only: cd milestone; ./product_build Then she/he should be able to come back a year later and build the same binaries. hmmm... it seems to me that what you want is what our release engineering team calls the baseline. this is basically the standard stuff that lives in /usr/include (only those things that really are standard across all distributions and come with backward compatibility guarantees), with assorted binaries, libraries, and of course the toolchain (compiler, linker, etc.). unfortunately, the exact composition of that baseline for OOo is not publicly documented; only release engineering knows what's really in it. everything that is not guaranteed to be standard across all distributions is in the modules in the external project. but for developers, the baseline is actually not really needed; afaik it is most important for doing releases that are binary compatible (for the parts of OOo where that is important) and that work on all semi-recent linux distributions. (of course, there are also baselines for the other platforms) an unfortunate aspect of the OOo build system is that there are actually two entirely different ways to configure it: one way is via autoconf/configure, the other one with special setsolar tool that only works in Sun Hamburg network; i believe release engineering is currently planning to or working on using configure everywhere: that would mean less stuff to maintain and keep in sync. regards, michael -- A novice was trying to fix a broken Lisp machine by turning the power off and on. Knight, seeing what the student was doing, spoke sternly: You cannot fix a machine by just power-cycling it with no understanding of what is going wrong. Knight turned the machine off and on. The machine worked. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: Build Comments
Terrence Miller terrencem at sbcglobal.net writes: I am about half way through my first build Hi Terrence, thank you for taking the time to report back. and have already run into things which could lead to unstable Linux builds: My experience has convinced me that any source information needed to do a build should be in a source file and stored locally. Well, for some stuff, that is not possible for legal reasons (licenses etc.). Examples of information that should be in a source files are: - A list of all the packages which need to be installed in order for the build to succeed. OpenOffice can be build almost selfcontained with almost no external dependencies. The deps start to get interesting when you use the --with-system- switch and use distro-provided packages. However, when reproducable builds are the aim (as are for our RelEngs), you wouldnt be using anything external, but use the library versions from the OOo repo. So the information is in the source files: The reference version of a library is the one found in the OOo repo. (better yet a script which will put a system in the desired state.) - the options specified to configure Thats a package maintainer task (as package maintainers might want to compile against patched libs, or enable/disable features). Also having any source files copied into external is (in my opinion) a problem. For example, the URL for gpc.[ch] could go dead overnight with no warning. Right, this is why this dep will be completely removed for 3.2. If OOo wants to be able to reproduce builds, we will need to have a local snapshot of any package listed as a build requirement. Where possible those are already in the OOo repo. Thanks for your comments and enjoy hacking OOo! Best Regards, Bjoern Michaelsen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: Build Comments
Terrence Miller terrencem at sbcglobal.net writes: In current scheme you end up running configure once for each missing package (since it stops on first error). Sometimes the error message is useful but not always. I understand the problem, but unfortunately maintaining an up-to-date complete list of deps is a lot of work (since those deps are also constantly moving). What we might try to seduce RelEng to is to make configure output all deps it is looking for, but I dont know if that can be easily (automatically) done. At least on Ubuntu there is a way to map from the name of a missing file to the name of the package supplying that file. Well, there is some kind of reference all the time - if you are not a package maintainer you can look at the source package of your distro. If you are a package maintainer, you can have a look at the source packages of other distros. A release is built with some fixed set of options. The documentation has an example for Ubuntu 9.04 but gives no clue what to do in any other situations. The wiki page is probably the wrong place for multiple examples Yep, those infos are kept in the source packages of the distro repo. Why would you want to do that in the first place? A year later so much stuff has changed in the sources - why would you want to build such an old version then? A critical bug in an old release has been reported by an important user and the latest release contains a UI change the user is unwilling to adopt. All relevant distros kept their source packages/ebuilds in a repository. Have Fun, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
