Change-Id: Iec214399f0cd8d5af198ad9080c55e5ee51a353d

Change-Id: I4bf39d3f4f21a0eb78e064c74ff47a47c9d0558c

But it built fine locally for me, huh. Oh well.

Change-Id: Icef376a26eb8069eff002b2112a25363b5e18cb3

Change-Id: Iff3b8e523f5d326586115c4ff61835c15b8b7f01

Change-Id: I2fc39999ecdb13eecc28e012debdeda811e98581
Reviewed-on: https://gerrit.libreoffice.org/5763Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

Add more FOO_FOR_BUILD variables and some gb_Foo_for_build functions.

Get rid of gb_INSTROOT and gb_DEVINSTALLROOT, just use INSTROOT.

Change-Id: Iee531b02d14fae41edb68ad589a5dec829a60255

This needs more investigation to find proper solution but the problem is
probably that URE/bin/cli_cppuhelper.dll is not signed by "sn.exe".

Change-Id: I318293603be838c41d09791136697de74091d37d

Change-Id: I4a9b34d63d2534a35aa9a878b8c2bec15262c2be

... for --enable-selective-debuginfo, use the right argument for that.

Change-Id: I34bc1f473e02d8f7038478afadc8de24780ae88a

Change-Id: Ib07f06b1fa0402795fa4b5b33574f53e4d266ab2

Seems to be a leftover of the String->OUString conversion?

Change-Id: I5ecbdbc0131894f5240b472d3981e69178b503c5

Change-Id: I269c5fd4817059f33df111f12ffd16ef8241a2fc

Change-Id: Iac32c42afef80e01af70479e5b2f9de4e1dfab26

Change-Id: I5982c44d5995baeaffff4ff12316f1f8fa7d0ade

Change-Id: I7b8c2e764da01e38fb9f7048bcaeca93a72fafa3

Change-Id: I949b62842d77fe83caed2cc79784fe1e3f3ae400

Change-Id: Id1e74f18c90e69d1a781c8f02e30dc3c005ed4fd

Change-Id: Ie7f33d0debfdb91db842608d5b14d0671b44c76d

Change-Id: Ib1869134b971c04a9cbd5d15b206898e943aaa5e

- fix the PATH
- file url needs to start with file:///X:/ (three slashes, literal :)

Change-Id: I0d16d1e946fd06ba5523961c23c3b46872c0c050

... should be obsoleted by previous commit.

Change-Id: I378de1465d293a60dc20c545770f029c8f71bd50

- StaticLibrary and CppunitTest have all files in one directory
- Executable may have the executable itself in a different one
- Library may have files in up to 3 directories

... so create 2 directories (which may be the same) in
gb_LinkTarget_LinkTarget and a 3rd one in gb_Library__Library_impl.

This allows to get rid of the "mkdir LinkTarget/pdb/..." thing in
the header target rule, which was always ugly since it did not
get rebuilt when deleting it (or whole LinkTarget dir) from workdir.

Oh and the pattern dependency causes trouble:

$(WORKDIR)/LinkTarget/% : $(call gb_LinkTarget_get_headers_target,%)

... for files in ExtensionLibrary; it would be possible to put
ExtensionLibrary somewhere else of course but actually this pattern
dependency is unnecessary since we get the same thing whenever any
object is added to a link target and there shouldn't be link targets
without objects anyway.

Furthermore directory dependencies must be on the headers_target because
MSVC will write a PDB file when compiling objects.

Change-Id: Icd92e8768d6aafb094a4144f90165aa5ff233647

There are 2 of these, one is written to by cl.exe and read by link.exe
and the second one written by link.exe.  Name the second one as the
linktargetname with .pdb appended, no need to substitue 5 different
crazy suffixes.

Change-Id: I2decad898ed1292b069bdda3124ce6f6c3667108

Not sure if it causes actual problems but all other platforms ignore
LIBS on static libraries already when linking.

Change-Id: I8a5ff4b2243b625827f82b0f64f007cea7c9d7c5

Refactor to find and link static libraries directly in WORKDIR.

- gb_StaticLibrary_get_target is now same as the gb_LinkTarget_get_target
- fix the StaticLibrary clean target

Change-Id: Icf29d32d6487747a2e39d4599ceebccfead04667

Change-Id: Id0c5908adbdec40346c1b62304d1f72ed077ca54

Note: do NOT put file paths to static libraries into FOO_LIBS variables
that are passed to bundled externals that are built with --enable-static:
on Mac OS X this will result in .a archives that contain other .a
archives as entries, and trying to link those results in errors like:

ld: warning: ignoring file .../libodfgen-0.0.a, file was built for
archive which is not the architecture being linked (i386)

Change-Id: If2c5a458058e4da76f80b3643e55b489d1edee24

LIBS is apparently used by autotools build system and passed to
configure at least in mythes and hunspell, where the LinkTarget variable
could cause problems by inheritance.

Change-Id: Ia267dd0a24c96914208869d7b47552b44a701735

If there are static libraries in $(LIBS) then things get really annoying
if they depend on other static libs that are StaticLibraries, e.g. orcus
and boost_system.  So reorder this to include $(LIBS) in the --start-group
--end-group and hope that doesn't break anything.

Hopefully $(LIBS) does not need -Wl$(COMMA)--no-as-needed, that should
only be required for $(LINKEDLIBS).

Change-Id: Ie15239a0fb7b5295f85941150e2c60912be73bfb

Call and link executables directly in INSTDIR.

- gb_Library_get_target is now same as the gb_LinkTarget_get_target
- disable gb_Library_add_auxtarget, no auxtargets need to be copied
- adjust paths of all external executables to OUTDIR_FOR_BUILD for now
- use lazy assignment instead of := in AllLangResTarget because it's
  read before Executable
- link.exe generates an import library for lots of executables
  because they export symbols, especially since commit
  0ffab936
  "force 'main' to always be DLLPUBLIC."

Change-Id: I3e1ee7425dd430bb83c7cd59e265869a0541b38d

... so that custom targets in i18npool run.  Can't remember if that is a
pre-existing problem or caused by one of my changes.

Change-Id: Ic0aa1f2b8600f4951d30a5ac6f3ade1a4fb2d313

Clean up the horrible mess around unopkg.bin unopkg.com unopkg.exe and
soffice.bin soffice.exe and crashrep.com executables and associated
renaming via Packages in the desktop makefiles by simply using
RepositoryFixes to correct the names.

Change-Id: I4d3a549462cfa90a63d62b35db1b0407b25239f7

The library is already in the URE/bin directory, but that is not
sufficient to be able to run sdk/bin/climaker.exe.

There are apparently 4 ways for a .net/CLR executable to locate
shared libraries:
1) in the same directory as the executable
2) in some mysterious "GAC" thing in C:/Windows
   (which is presumably how it works if you actually install LO)
3) via an application configuration file entry "probing",
   which only works when it's in a sub-directory of the
   one the executable is in
4) via a DEVPATH variable, but that only works with a
   special configuration entry in a system "machine config" file
   of the .net framework

Specifically PATH is apparently ignored.  Since building on Windows is
enough of a PITA already and we don't want developers to have to edit
another config file, put another copy of the library into sdk/bin.

http://tutorials.csharp-online.net/.NET_CLR_Components%E2%80%94Resolving_Names_to_Locations
http://tutorials.csharp-online.net/.NET_CLR_Components%E2%80%94CLR_Loader

Change-Id: I511957ad9a9a918ed0c316126304a1980fb2d289

Change-Id: I76b4815208354e78eb3575982235b6f26f1e02fd

Putting it in a subdirectory on solver is no longer necessary since
python3 started delivering to INSTDIR, so lose the crazy naming.

Change-Id: I17e924e5d872768a64f6a3112f1294f3def7120e

... and put it in OOO layer since it's used by the smoketest instset.

It was in subdirectory for hysteric reasons, to pick up libraries from
module local output directories in the dmake build system.

Change-Id: I73b66672b17ede52c03071eb2ddee1a23c059ea9

This is somewhat annoying since it requires re-introducing stupid
directories in scp2, but if the executables should be put in INSTDIR
directly then the Package_bin needs to go.

Change-Id: I893694c7f9d4cb5b9ef8ec4a3d30e08536223740

... because this is the time of day when one thinks, wouldn't life
simply be more awesome if there were a SHLXTHDL layer?

Change-Id: I02df8a8bf9d7d641ea060e2cfef6643fe2202353

Refactor everything to find and link libraries directly in INSTDIR.

- add gb_LinkTarget_get_linksearchpath_for_layer, and use it to set up
  -L paths for T_LDFLAGS in such a way that only allowed libraries
  can be linked against; i.e. it's not possible to link URE
  linktargets against OOO or not-installed libraries
- gb_Library_get_target is now same as the gb_LinkTarget_get_target
  (TODO: this needs cleanup)
- since a pattern rule won't work for linking libraries in INSTDIR,
  add a separate per-file rule for every INSTDIR lib
- pattern rule can't find link target in the clean target any more
  so add a LINKTARGET variable
- disable gb_Library_add_auxtarget, no auxtargets need to be copied
- tweak the call to gb_Library_Library_platform to pass in a path
  in sdk/lib for the versioned URE libs
- fix the Library clean target
- add LAYER parameter to gb_LinkTarget_LinkTarget
- adjust platform link commands
- MSVC link command now uses explicit -manifestfile and -pdb
  parameters to keep misc. files out of INSTDIR
- remove gb_Helper_OUTDIR_FOR_BUILDLIBDIR
- adjust Extension, CppunitTest,  JunitTest, PythonTest, Gallery,
  various CustomTargets to search INSTDIR
- remove SDK library symlinks and import libs from odk/Package_lib
- on Mac OS X, put .dylib symlinks into sdk/lib even though those
  are not packaged and would be created by the SDK configury;
  we need these to be somewhere for linking anyway
- add a (unfortunately cyclic) dependency on Package ure_install to sal

Change-Id: I70d88742f8c8232ad7b9521416275c67b64fe6cf

It is actually installed by scp2/source/ooo/ure.scp already.

Change-Id: I0ca538e3d6c52b1e228f1b1191778d8fb5d84954