..since it also needs stuff from postprocess.
In qa/desktop/Makefile, images_tango.zip is used.
If that's not needed, the module can be placed between postprocess
and packimages for now.
Change-Id: I9951cce0c8da0fc75fd8a7b1246f4083bd38f705
Yes, I know that eventually what now is known as "tail_build" will be
all there is left. So by that time, by definition nothing can be built
"after tail_build". Will have to handle that then.
Change-Id: I47d228ca7156520db10630861ce52b015a7a169c
Just build the sdremote app for now. Note that this is a pure Java
app with no dependencies on (native) code (or Java code, for that
matter) from rest of LO.
Probably should drop the separate android/sdremote/Makfile and just do
what it does in android/CustomTarget_sdremote.mk instead.
Adding other Android apps (well, the LibreOffice4Android one likely)
to gbuild will require more complexity as they bundle native code, and
thus should depend on other modules first having been built. If one
wants to go really fancy, one could of course depend on the specific
libraries (and other files) being bundled. Let's see...
Change-Id: If10761479f348c4993eec40b7f8346edb77f0e0d
This enables to properly use make <module>.all for builds without
dictionaries and hopefully also solves the problem behind
5133d3c48f
Change-Id: I43872864aa135014ea51d15b34ef4de151f14c3d
Introduced special token LIBO_DEV_INSTALL=TRUE to communicate what install set
to build from Makefile.top's dev-install target to
instsetoo_native/util/makefile.mk. Somewhat arbitrarily, always use a "release"
install set regardless of --enable-release-build (the dev-install set is used
for "make check," and it is safer to test "release" install sets in
--disable-release-build builds than the other way around, should those builds
ever start to deviate significantly).
The "always build a defaul-laguage openoffice product" logic had been obsoleted
a long time ago already.
Change-Id: I64ec87a0b8dc6fe81cab5531c43e29db3f5128af
This is a partial revert of 0ec45dc41d ,
mainly for tinderbox nightlies. The .zip for dev-install is built
only in dev-install target. But IMO the build target is broken
this way too, I don't see why the .msi has to be built already there
and not in some install or make-msi or whatever target (it's pointless
in build target for a developer build).
Change-Id: Ifd63066499b67fa446127193b243d893d497b451
Forcing creation of second installation set is perhaps not ideal,
but i have no idea how that installer perl crud work and
at least it gives something to run tests against.
Change-Id: I506160013de23f76128c9e39b4f3bacc6e32cc7a
The top-level Makefile invokes autogen.sh (and thereby configure) in an
environment which is polluted by config_host.mk; this causes at least
the problem that following a "make clean", the bootstrap script will not
copy dmake to its destination because BUILD_DMAKE=NO is set from
config_host.mk, which is apparently due to the PATH being polluted from
config_host.mk, so configure finds the dmake in the build tree.
So split up top-level Makefile into Makefile, which invokes autogen.sh,
and Makefile.top, which does everything else.
