Hi Laslo,
> and then in config.mk have a variable
>
> TARGET = arm
>
> and then in the Makefile have a line
>
> include target/$TARGET.mk
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...
> So did you build all of the platforms or would it need to be
> selectable? If you have multiple platform sources e.g. in folders "x86"
> and "arm", I would create a folder "target" that contains the files
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.
Best regards,
Ralph
--
Tai Chi Minh Ralph Eastwood
tcmreastwood_AT_gmail.com
Received on Sat Jan 01 2022 - 17:03:41 CET