Re: [dev] Special target ".POSIX" in Makefiles

From: Laslo Hunhold <dev_AT_frign.de>
Date: Sat, 1 Jan 2022 19:05:12 +0100

On Sat, 1 Jan 2022 17:03:41 +0100
Ralph Eastwood <tcmreastwood_AT_gmail.com> wrote:

Dear Ralph,

> Thanks for pointing out that technique, I've utilised it in the past
> and it's a shame that it's not more well-known... I've seen many a
> GNUism in its place...

yeah, it makes a lot of sense and is nice and simple.

> The idea was to build all the platforms' binaries out of the source
> tree. For example, having an 'obj' directory separate from the 'src'
> directory and then dumping the built objects into there. In the
> context of multiple platforms, then you would have 'obj/x86',
> 'obj/arm' etc. So taking your example:
>
> make TARGET=x86 # obj/x86 is populated with *.o, bins
> make TARGET=arm # obj/arm is populated with *.o, bins
>
> The benefit of having it out of tree is so that you do not need to
> `make clean` and lose previously built object files.
>
> As far as I'm aware, suffix intrinsic rules like:
>
> .c.o:
> $(CC) $(CFLAGS) $(CPPFLAGS) -o $_AT_ -c $<
>
> only allow you to implicitly define rules that have the target suffix
> (.o) and the source suffix (.c) as long as the prefix is the same.
>
> My thoughts have always been to not have this as part of the
> make-step, and that platform (or generally configuration) specific
> building should be done in an external step (be it a shell script or
> some overly-sophisticated CI [another topic]).
> An alternative could be a script or even make step that can
> 'save' and 'restore the build state of a particular platform into the
> 'obj/$(TARGET)' directory.

If you think about it, a better approach in this case would be to pack
these things into a static library (which is basically a collection of
object files). So you would have a target

   library-$(TARGET).a: $(SRC:.c=.o)
           $(AR) rc $_AT_ $?
           $(RANLIB) $_AT_

(where AR and RANLIB are defined in config.mk) that you could rely on
in higher levels of the program. This single file also allows you to
easily move it around and swap it.

The make-clean-matter can be resolved insofar that you only cleanup the
static library of the current target, i.e.

   clean:
           rm library-$TARGET.a $(SRC:.c=.o)

which then yields a build environment where you can work on the arch
that matters at hand without having to recompile the other stuff (which
stays "stale" and can be linked into your program without issues).

However, if you want to clean everything up and rebuild everything, you
just have to remove all the static libraries and regenerate them (either
automatically by invocation from a higher layer or manually).

With best regards

Laslo
Received on Sat Jan 01 2022 - 19:05:12 CET