Age | Commit message (Collapse) | Author |
|
Change-Id: I5388132b0dbb0d904a5b235139bfa1f0e078e5ba
|
|
Change-Id: I62c72e499119eb43ed0c75fe1f5cb1c9fc06c113
|
|
Change-Id: I4ad94eca4ebbf7d8e989dba5a19296d727111850
|
|
Change-Id: Id54050f483aabf3514e4dd122ef295c6f1135fe4
|
|
Actually I think it should be removed entirely, because dmake already
includes minor.mk directly from solenv, but I do not want to pry into it
right now...
Change-Id: I51520642f4796d722cb2131e91e9e92a82920531
|
|
Change-Id: I8a4b11c14c615ba47c8e58b5f30145f5e8d77f0d
|
|
Change-Id: I430fcca0df44966e05a57d1cafd16d18bebdca81
|
|
This makefile must be included from other makefiles, which means it must
be delivered first, which does not play so well with gbuild's
all-in-one-process build. Because the version has not changed once since
the library was introduced in 2006, I consider this just an unecessary
complication of already complex build process.
Change-Id: I8304f0e8ef9e59a046b10f423dbe61d75e3fc5c2
|
|
There are several modules in tail_build now that are depended on by
other modules from postprocess (e.g., pyuno depends on 18npool). That
means that build.pl actually schedules i18npool (and its parents) for
build. This is fine for build.pl -P1, but it could be a problem for
build.pl -P2. It is also wasteful, because we are not actually using
tail_build to the full extent.
This gross hack schedules all modules that depend on any tail_build
module _after_ tail_build, so all modules that are in tail_build are
only build in tail_build.
Change-Id: I39840c1cbbfc5024f0009296416c628be028657a
|
|
Change-Id: I40df9611be87830e4938ee20a4e3be19767ddfad
|
|
Change-Id: I6662bfca925f9dae99b3f70fd81dba04d36ac9c8
|
|
Change-Id: I223122d9f99c8068af21c80f9b52642c762c79af
|
|
Change-Id: Ife00d7477dacfe1eb325c722517fb038ead083db
|
|
Change-Id: I2ebcacc089d86c9de85b617d80d6a557498d8add
|
|
Change-Id: Iae3e78e2abe59714d5eb9fa0609861a00e85c944
|
|
Change-Id: Ib1d9cd1dc1e9c24a5a72c51060797f2214a95c89
|
|
Change-Id: If9a0906a76943160cfdbd647b26a801bc4389615
|
|
|
|
So it is easier to check differences between install scripts generated
by dmake and gbuild.
Change-Id: I12bbdf481c84c896b67a94eaca6460ffb52d96ec
|
|
Change-Id: Ifce1f75f8de0cd35dd744dfd39af7aefef512ecc
|
|
Change-Id: I4ee6eb456bf400747c2e397ec6cd402fb6251bc6
|
|
Change-Id: Ie6a68d9ed96e35f6e8c4778bcd4fd8920d19159c
|
|
Change-Id: I572a8a6dc9da4f63b7c937748b3013bab60bb6bb
|
|
Change-Id: I91a89f9d0bd1eb88a94179f1c1a41bc832599fed
|
|
Change-Id: I2908d5851ae33d70a49a032130fdc1a406310c7d
|
|
|
|
|
|
Change-Id: I6e9a9bc1f35be02af40530b29044e1f4b33e91ab
|
|
Change-Id: Iebb6fede055f274d66aa09344b911913d5cb9882
|
|
Before gbuild'ification, solenv/inc/target.mk carefully produced two variants of
each type rdb, a plain one from calling idlc w/o -C and a *_doc variant from
calling idlc w/ -C ("generate complete type information, including
documentation"). After gbuild'ification, solenv/gbuild/UnoApiTarget.mk
unconditionally only produced "complete" type rdbs from calling idlc w/ -C.
It is unclear to me whether the old *_doc variants had actually been used for
anything (what got packaged into installation sets apparently were the plain,
slim variants; and autodoc apparently does not need the *_doc variants, either,
as it produces UNOIDL documentation directly from .idl files). It is also
unclear to me whether the gbuild switch to effectively package complete, fat
rdbs was deliberate or not. (The only client-visible change I see is that low-
level C/C++ typereg_reader_getDocumentation could now report something. The
reflective UNO services at com.sun.star.reflection would not offer access to the
documenation anyway, however.)
The benefit of no longer including documentation in the packaged type rdbs is
size; the URE types.rdb shrinks from 1.2 MiB to 819 KiB, and offapi.rdb shrinks
from 11 MiB to 6.5 MiB.
Change-Id: Ib278f74fc3b22169e00a09d778807f8cf58520c4
|
|
Change-Id: I7d409fbe813f07dc87301b6c6f01a40f531d368c
|
|
Change-Id: I241be2704a069ec1f6be5861084039569673cc12
|
|
|
|
|
|
Change-Id: I49986d6feac5e46c7b2f3017cf97b07dce4db42f
|
|
Change-Id: Ia2b63502dbd8b5e4e0ca7faa34e06df73f094a78
|
|
Without this, when changing sdi file, the objects that include the
generated header are only rebuilt at the second make invocation.
Change-Id: Idd52a12dd162ec780da3a3b9f24d3bdd9b408a33
|
|
|
|
Change-Id: I29310b2c53258201609983b0a2c7292ced0614f9
|
|
Change-Id: I6e0758e543a89f593a1b0432b28b4c9768993af7
|
|
Change-Id: I97e6d26a33e18f0303742c930478a8ebac13a7b0
|
|
Unfortunately this --enable-dbg-util only problem (caused by
_GLIBCXX_DEUBG) resurfaced, perhaps because of new std::string based
logging in sal; adapt all map files to export the unique symbol.
|
|
Change-Id: Ifb9f4627c15d5f1410af2b87bf2e2f39c945671c
|
|
The only task of the UnoApi class is to deliver a RDB file and all the
stuff related to it (i.e., the IDL files and the generated headers). For
that purpose, order-only dependecies are sufficient.
Change-Id: Ibe0a58d1e8ceaad62ff71773e372fb8dfb921fbd
|
|
This reverts commit 07c0b800d9d70857882238204820f75b8dc98b26.
|
|
Change-Id: I4cfe3ce7b7dab5d3fb2d3ddfa28f0fa263593667
|
|
Rules that invoke generated executables should have dependencies on
those executables.
|
|
With the way dep-file generation was changed for LinkTargets in
8b5a984d45005d3df1c89eae897d6e04612625d8, it is necessary to change all
other dep-file generation the same way, because the LinkTarget dep-files
are outdated wrt. the object dep-files after an initial make run, and
hence if any other dep-file depends in any way (even build-order) on a
generated Executable, say by depending on the corresponding target file,
then the PHONY entries in the outdated LinkTarget dep-files for the
executable and its linked libraries cause all these objects to be
recompiled.
It is not a problem that there is a rule with the dep-file as target,
and another rule for the corresponding actual target that writes the
dep-file as a side-effect, without dependecy between the targets:
because make does processing in 2 phases, first building all included
makefiles, second all other targets, it is guaranteed that the 2
commands don't race to overwrite the dep-file because (when there is no
dependency between them) they will not be executed in the same phase.
The only problem here is that this will probably make IDL processing a
lot slower on Windows, writing all those dummy dep-files.
|
|
The LinkTarget dep-target depends on the LinkTarget headers target,
which appears unnecessary and harmful because since commit
8b5a984d45005d3df1c89eae897d6e04612625d8 the initial dep files always
contain PHONY deps anyway; also the PHONY deps cause spurious re-builds
here because e.g. the tools library depends on a tools package that
depends on a tools custom target that depends on some executable
that depends on libuno_sal that depends on its objects which depend on
this PHONY thing so all that stuff is spuriously re-compiled in make
subsequentcheck after a build from scratch, breaking tests because
being subsequent they don't expect libraries to change under them.
Also, link target shouldn't depend on its dep target.
|
|
The OUTDIR RDB depends on Packages for IDL and headers, the latter of
which depends on the WORKDIR RDB, hence preserving timestamps here leads
to spurious re-delivery because the OUTDIR RDB always has older
timestamp than the headers Package.
|