summaryrefslogtreecommitdiff
path: root/odk/CustomTarget_settings.mk
AgeCommit message (Collapse)AuthorFilesLines
2024-05-03makefile simplification: replace $(call gb_CustomTarget_get_workdir,foo)Christian Lohmaier1-1/+1
…by a simple/static $(gb_CustomTarget_workdir)/foo The build system has a lot of overly complicated leftovers from when it was introduced and had not only deal with split repositories but also had to coexist with another buildsystem. Along with lots of copy'n'paste along the years the makefiles became hard to grasp for newcomers with all our calls and evals. As a first step to streamline that, the macros from TargetLocations that simply prefix a static path to the argument (and similar of the same kind) are a natural pick before simplifying the rules themselves/getting rid of a bunch of eval statements. Change-Id: Ia06dbbcd5d1994755a2ff05b84f72ccbc4e3cab5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167005 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2014-01-30SDK: Split PLATFORMID at build time rather than runtimeStephan Bergmann1-1/+3
...where $(shell printf ...) in settings.mk likely doesn't work on Windows. Change-Id: I64a51203d1bf131160768f9a9069f428228aa6b1
2014-01-20SDK settings.mk: Don't guess PLATFORM/PROCTYPEStephan Bergmann1-1/+2
...rather, pass them from the build to the SDK installation via dk.mk. (The SDK installation is already platform-specific anyway, see the binary executables in its bin/ directory, so there is no point in not fixing this at build time. In the future, the shipped settings.mk could of course be stripped to just the parts relevant for a given platform, of course.) Along the way, fixes some apparent "ppc" vs. "powerpc" typos in settings.mk. This is a prerequisite to create a working settings.mk for macosx_x86_64, but does not yet do that. Change-Id: Ib8e0c03ad6dfd610aae58a61e32bdc61c785584f
2013-09-11odk: move files out of the confusing "pack" directory to better homesMichael Stahl1-1/+1
Change-Id: I46f4954ef07f60e1f7824a47f0617f8612ea9505
2013-05-04drop unneeded odkcommon/David Tardon1-3/+3
Change-Id: Id88a58e43fd7a39fdbc7545a0618b05070b1270e Reviewed-on: https://gerrit.libreoffice.org/3776 Reviewed-by: David Tardon <dtardon@redhat.com> Tested-by: David Tardon <dtardon@redhat.com>
2013-04-22replace CustomTarget_odk/odkcommon/settings by PackageDavid Tardon1-18/+2
Change-Id: Iee97a510be822836b2115f50d0b1c9e7e14b5e1a Reviewed-on: https://gerrit.libreoffice.org/3534 Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org> Tested-by: Fridrich Strba <fridrich@documentfoundation.org>
2013-04-19Adapt SDK to usage of msvcrtd for Windows --enable-dbgutilStephan Bergmann1-1/+2
* Re-use existing settings/dk.mk to tunnel ENABLE_DEBUG into the SDK. Turns out this was explicitly included in ~all examples Makefiles, but only after settings.mk where it is now used, so include it in settings.mk now and dropped it from all the exmaples Makefiles. * The old settings.mk was apparently confused with using /MT ("link with LIBCMT.LIB") on cl command line and /MD ("link with MSVCRT.LIB") on link command line (where it was ignored), and you apparently can't pass both together to cl, so I settled on /MD (resp. /MDd) now and dropped /MT (resp. /MTd). No idea if that is exactly right, however. * Introduced client-facing LIBO_SDK_LDFLAGS_STDLIBS that covers kernel32.lib and msvcrt.lib vs. msvcrtd.lib on Windows. Adapted examples Makefiles and /ure/source/uretest/Makefile accordingly. Some examples Makefiles additionally use msvcprt.lib, no idea whether that still needs to be addressed. Change-Id: Ia8d9d177e415abfbaf6f9fa6239f0ef9998868be
2013-03-19odk: do not pack unused component.map fileMatúš Kukan1-13/+0
Change-Id: I768acf83234eec46c0271dad2e5bef3bd3cba3cf Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
2013-02-23convert odk to gbuild and add to tail_buildPeter Foley1-0/+48
Change-Id: I8e8de7f2bb87cce7916c7c2df24c1b0ddaea55c0 Reviewed-on: https://gerrit.libreoffice.org/2288 Reviewed-by: Peter Foley <pefoley2@verizon.net> Tested-by: Peter Foley <pefoley2@verizon.net>