| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
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
|
|
Change-Id: Ice9bf5cbd894950ef3db5fb32778c83bc4ab5baa
|
|
Change-Id: I0a3ad6553692fc21eaf96cf35e9c343b4d716c21
|
|
make 3.82 understands mixed paths, so use them.
This allows us to get rid of evil in BuildDirs.mk.
Hopefully, life will be simpler now.
Change-Id: I I I641f28c6af1948963f7004f8071af62e21caabb3
|
|
Change-Id: I706593f0017d440b486f698d1158f070df4e8b2e
|
|
Let --enable-debug determine whether optimization should be disabled,
which works also for debug=t due to the setup in gbuild.mk.
Also clean up uses of gb_COMPILEROPTFLAGS: this is now always set to
optimization settings, and gb_COMPILERNOOPTFLAGS used in debug case,
which should not make a difference because the only actual difference
was that on MSVC the debug OPTFLAGS were empty, but -Od is documented as
the default for this.
|
|
OOo used to use debug level this way:
0 is default for product build
1 for --enable-dbgutil
2 for environment variable debug=t, regardless of dbgutil setting
in LO these have now morphed into:
0 is default for product build
1 for environment variable debug=t
2 for --enable-dbgutil (at some intermediate stage in the past)
1 for --enable-dbgutil (today)
This has caused a lot of confusion and some things were not converted
properly, including a check in LinkTarget.mk.
Developers should use --enable-debug to get useful information,
including full debug info and assertions.
--enable-symbols is not intended for developers, but for people
who need their builds to be able to produce useful stack traces;
--enable-symbols is for example set unconditionally in the Fedora RPM
spec, and for this purpose disabling of inlining is not wanted.
It is unlikely that somebody wants symbols for only part of the build,
and consequently a different mechanism is used to set the corresponding
flags: they are set into global gb_LinkTarget_C{,XX}FLAGS.
So move the selective symbol feature back to --enable-debug.
(this substantially reverts db8df57acd601ed084bd0122683e1bd066a4f143)
|
|
(was broken by ebed42c38ae91147633c47873307e07984bc62c1)
|
|
|
|
|
|
GNU coding standards say that user should be able to override the build
system's default flags with CFLAGS/CXXFLAGS environment vars;
also these ended up twice on the command line due to historic accident.
|
|
The previous commit works but results in a ~0.4 second slowdown on
tail_build, which is completely unacceptable; seems that at the cost of
another ugly global variable in Module.mk we can get the performance back
and then some, so refactor this again...
|
|
so it doesn't use wildcard but instead the actually registered
LinkTargets.
|
|
Change-Id: Ia4ac141d8e054d8558d77251c6f069a51a7e6fab
|
|
Change-Id: Id3d8313eabcef926b3ab3c121597f7b8cb5e0124
|
|
Change-Id: I35c88dc5ffe1b4082d0ef9611dd2c698c0d4217e
|
|
|
|
|
|
|
|
|
