| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
When install location is writable to user (typical on Windows XP),
Python generates .pyc files. We can remove them using the RemoveFile table
in MSI. We generate an entry for each .py file in the install set.
Change-Id: I314582d52162c6f3ae3acc72de9d620680fb23e0
|
|
|
|
| |
Change-Id: Id88f38fb806c6178240eb69da69c2e633c2033da
|
|
|
|
|
|
| |
...so they do not erroneously inherit values from other targets.
Change-Id: I6c84cecad4ea858b77d5d83eb93938c397aed076
|
|
|
|
| |
Change-Id: I6f468005c8d8d99d9251a9c4fe4629b98bc4aa5e
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some circumstances installation of embedded VC++ runtime
fails with error code 1935. This usually occurs, when there are
many different versions of VC++ runtimes installed on the computer,
including beta versions. We can workaround this Microsoft bug, if we
don't install our VC++ runtime. A new property was introduced. It is
called VC_REDIST, and installation of VC++ runtime depends on its
value. (BTW the solution is general, ComponentCondition can be used
for any merge module, now we have only the VC++ runtime merge module.)
When the user experiences error code 1935, he should try to install
LibreOffice with the following command line:
msiexec /i <msi file name> VC_REDIST=0
The patch fixes another minor issue. 64-bit VC++ runtime will
not be installed on 32-bit systems any more.
Change-Id: I I6c5e066c6e60b011235e6019a8a35c9e953209bc
|
|
|
|
| |
Change-Id: If0b7234ede1d9f8c59e5df692b45539a508d8921
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 875c9a28f49c7a73607fcdfac245b648801dccee.
because it doesn't make sense to build the dmake modules
without -fsigned-char and the gbuild modules with -fsigned-char
and we're still got a few bugs where we assume chars are signed
Conflicts:
solenv/inc/unxlngppc.mk
Change-Id: I6ac07fa3ebadd83efd0da1ee69a010b62dfaad59
|
|
|
|
| |
Change-Id: Ib119c7bf8e04b8274026159218281cb3f220c8d0
|
|
|
|
| |
Change-Id: Ia7d13e9e91f12a6f98eb51ed7d92ff14a5c8454d
|
|
|
|
|
|
|
| |
Move initialisations of gb_CFLAGS and gb_CXXFLAGS earlier, like in
unxgcc.mk.
Change-Id: I2382edad42f0f52bcbb062ec6930e2cfe12ec8ca
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the tests detect that visibiliy works, then use it also in
gbuild. In the old build system, -fvisibility=hidden was already
being used on Mac OS X if HAVE_GCC_VISIBILITY_FEATURE had been
detected.
In configure.in, let's not hardcode the -shared, -fpic and -Wl,-z,defs
options or the .so suffix used in visibility-related tests. Factor
them out and use platform-specific options. Done just for Mac OS X so
far. Using the Linux options for Mac OS X caused visibility tests to
silently and misleadingly fail.
Yes, it is silly to now define some platform-specific options in three
places: configure.in, solenv/inc/* for the old build system, and
solenv/gbuild/platform/* for gbuild.
At least with my Xcode3 installation, I need to pass an -isysroot flag
pointing to the SDK when running $CC -E, otherwise headers weren't
found. This was then misinterpreted as the visibility tests failing.
Pass -DHAVE_GCC_VISIBILITY_FEATURE to the compiler if configure
detected visibility working. In that case also pass
-fvisibility=hidden. HAVE_GCC_VISIBILITY_FEATURE being defined is
supposed to mean that the -fvisibility=hidden option is used, I think.
Pass also -fvisibility-inlines-hidden if that was detected to work.
Change-Id: I I I58d566fcb07584246e91f45e683ce9b31208edba
|
| |
|
|
|
|
| |
Change-Id: I I I0bfc367a3b2c551509b383fc4f6dcaa3cb8661f8
|