[ANN] feature/instdirlinktargets merged (was: Re: minutes of ESC call ...)
mstahl at redhat.com
Sun Sep 22 02:24:10 PDT 2013
good news everyone!
On 19/09/13 17:16, Michael Meeks wrote:
> * Solver killing (Matus / Michael S)
> + most of the difficult work is done
> + now only one copy of dynamic libraries & executables in instdir
> + already working on Linux
> + working on static libraries
> + should save a chunk of size in the build-tree
> + around 4-5Gb if built with debug in the solver
> + always used to store it twice -> the solver
> + with instdir - store it 3x
> + will get it down to just once.
> + fixing library search path, so layer of link target is right
> + so can't link an extension vs. comphelper anymore
> + still some bits left in the solver
> + hopefully not as difficult to remove.
the branch (feature/instdirlinktargets) is now merged on master.
make check passes here on Linux and Windows, and on Mac OS X i can build
an instset. but cautious people may not want to trust me and get a
second opinion from tinderboxes :)
a "make clean" is required when you pull this.
i'm pretty sure this will break builds with --enable-mergelibs,
Android/iOS, cross-compiling, gb_Package_PRESTAGEDIR and other exotic
configurations; but my hope is that if you use that sort of thing you
should be willing and able to fix it again :) [ probably cross-compile
will need a INSTDIR_FOR_BUILD now... ]
on Fedora 19 things are a bit smaller now (--enable-dbgutil):
> du -sh workdir instdir solver
... though i wonder why on Mac OS X a very similar configuration is much
$ du -sh workdir instdir solver
guess the clang++ is using a less spacious version of debug-info...
> du -sh workdir/unxlngx6/CxxObject
$ du -sh workdir/unxmacxi/CxxObject
there are still 853 files in solver/unxlngx6, but the hope is that these
are quite easy to remove one makefile at a time, unlike the tangled mess
that is linktargets; interested people are of course welcome to help out.
some easy bits are the various libraries delivered via ExternalPackage;
there are even libfoo.so.X.Y.Z files in solver that probably have never
had a need to be there.
... and another nice thing about this is that with every library
existing only once, it was very easy to finally get the PythonTest to
work in a MSVC build too; previously it failed because it somehow
managed to load 2 copies of tklo.dll; so hopefully PythonTest is now
working on all platforms where JunitTest works.
More information about the LibreOffice