…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>
make removes partially built targets in case the rule exits with
non-zero status, so creating a temp file and moving it is not necessary
also use single quotes for cases where characters might be interpreted
by the shell
Also combine multiple sed calls into a single call of sed with multiple
expressions and replace additional "grep -v foo" with corresponding sed
delete command
Change-Id: Iff7e3b962175e347e5ed100a87c96fbaeef39985
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166410
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
...where $(PYTHON) is undefined, but which was mostly masked by
solenv/bin/gentoken.py happening to have a shebang line, except for flatpak
builds now failing with
> /usr/bin/env: ‘python’: No such file or directory
> make[1]: *** [/run/build/libreoffice/editeng/CustomTarget_generated.mk:18: /run/build/libreoffice/workdir/CustomTarget/editeng/generated/tokens.gperf] Error 127
(See also discussion in the comments of
<https://gerrit.libreoffice.org/c/core/+/89262> "Convert gentoken from Perl to
Python.")
Change-Id: Iebdf98d7b7ee4da9d861231064549ffef5445edc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89828
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Follow-up to d8106b6db4 "Non-standard sed -i
option is different on macOS than with GNU sed", thanks to mst for spotting it.
Change-Id: Ida51cfa7c4dd216a5164df4f8143ac89cf2c6b7f
Reviewed-on: https://gerrit.libreoffice.org/66498
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
While with GNU sed the optional backup suffix is given directly as part of the
-i[SUFFIX] (or --in-place[=SUFFIX]) argument, on macOS it must unconditionally
be given as a (potentially empty) argument following the -i argument. That
means that on macOS the -e that happens to follow the -i in these sed
invocations (and that happens to not be necessary to introduce the following
script in these invocations) was mistaken as the backup suffix, causing creation
of pointless workdir/CustomTarget/*/generated/tokens.cxx-e backup files.
Change-Id: Icd865c76139afa348d03813eb83653afd7221a0e
Reviewed-on: https://gerrit.libreoffice.org/66491
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Caolán McNamara