By using names like COMPILE.c and LINK.lib, this will make it easier to
generate build rules more easily based on extensions
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
Earlier, $(PREFIX_LIB) would be the path for libraries,
but also for installation. That led makefiles to adjusting
the prefix in order to install in some subdirectory.
That does not work in a distro setup where PREFIX_BIN
and the like are provided by the build environment,
and represent the base of that build environment.
MinGW now seems to be able to cope with the -rpath option in ld.
However, it's necessary to place LDFLAGS after objects, as observed
with BUILDENV-specific LDFLAGS, i.e. LDFLAGS_BUILDENV_mingw=-lregex
While it's OK to link a library by giving its .a name, it doesn't
work well when linking with a .so, since it encodes the full path
of the .so name in the result
A number of changes in this commit:
1. Variable namespace cleanup:
Rename non-configurable variables as MIQ_XYZ.
2. Internal target namespace cleanup
Rename intermediate targets to begin with a dot (.)
For example .build, .prebuild, etc.
This impacts makefiles that hook for example to prebuild
(now they need to hook to the .prebuild target)
3. Target, variant and build-environment variables names
For example, dependencies on $(TARGET) moved from DEFINES_xyz
to DEFINES_TARGET_xyz instead of DEFINES_xyz, and same thing
for includes, sources, etc.
4. Protection of special user-level top-level targets
A target like log-% no longer interferes with a file name such
as log-file.c
5. Better support for multiple products
When building foo.exe and bar.lib, there can be different
sources for each project, i.e. $(SOURCES_foo) and $(SOURCES_bar).
This simplifies the management of projects using make-it-quick by
putting the makefile include files in a shared location
(typically /usr/local/include/make-it-quick)
The problem was discovered testing parallel builds.
The configuration rules depend on generated pkg-config.mk files.
However, experimentally, variables set in these files are not
correctly reloaded in rules declared in other variables.
Specifically, $(CFLAGS_PKGCONFIG) was not re-expanded after being
modified, which led to configuration builds to lack the required
flags, causing false configuration step failures.
The flags are now explicitly listed using $(shell cat...), which
is a little bit more expensive during the configuration step, but
ensures that the flags are correctly seen. Note that at that stage,
the dependency ensures that all the files were built correctly.
Christophe de Dinechin