[chbot] Is there a GNU makefile guru out there?

Charles Manning cdhmanning at gmail.com
Mon Aug 3 08:54:26 BST 2020


Another thing worth considering is dropping the notdir bit.

OBJECTS = $(addprefix $(BUILD_DIR)/,$(C_SOURCES:.c=.o))

That will mean you get the objects created in the same directory structure
under the build to prevent file names from stomping on eachother.

I quite often use makefile includes to cover the common files, then still
use a project make file per project which then includes the common include
file.

Example here:
http://www.aleph1.co.uk/gitweb/?p=yaffs2.git;a=blob;f=direct/test-framework/tests/Makefile





On Mon, Aug 3, 2020 at 6:32 PM Volker Kuhlmann <list57 at top.geek.nz> wrote:

> On Mon 03 Aug 2020 16:54:17 NZST +1200, Robin Gilks wrote:
>
> [Makefile for different projects]
>
> I've done fairly extensive Makefile construction, but haven't had to
> make major changes in a while. I can see 2 approaches here:
>
> 1) Share a Makefile
>
> Use shell globs to create the sources list, and run the Makefile in the
> project directory.
>
> Alternatively, use static sources lists, but then you'll have to assign
> variables dependent on the currently active target. It works, but can
> get a bit unpredicted because IIRC the assignments were not
> hierarchical, i.e. when a sub-target is made, the assignment disappears.
> Using both immediate and deferred variable assignments cleverly might
> help.
>
> I'm not sure having the same Makefile for when you add projects later is
> a good approach. Makefile changes for projectB might change the build of
> projectA.
>
> 2) Have a Makefile per project
>
> This is usually the done thing. You can place the not-changing bulk of
> your Makefile into common, and use include. That's what I do. Make a
> template Makefile and include everything but the differences for this
> project. Parameterisation is good.
>
> You could add a top-level Makefile that makes all in subdirectories.
>
> If however your projects are different build variants (I have that
> lots), suitable parameterisation should do wonders.
>
>
> Always use implicit rules. As soon as you have explicit rules, things
> get complicated. The exception is where your explicit rules are
> automatically generated. There's a gcc option to auto-create the
> dependency list for each module. That's a good one to use too.
>
>
> Or did I misunderstand your requirements?
>
> Volker
>
> --
> Volker Kuhlmann
> http://volker.top.geek.nz/      Please do not CC list postings to me.
>
> _______________________________________________
> Chchrobotics mailing list Chchrobotics at lists.ourshack.com
> https://lists.ourshack.com/mailman/listinfo/chchrobotics
> Mail Archives: http://lists.ourshack.com/pipermail/chchrobotics/
> Meetings usually 3rd Monday each month. See http://kiwibots.org for
> venue, directions and dates.
> When replying, please edit your Subject line to reflect new subjects.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ourshack.com/pipermail/chchrobotics/attachments/20200803/fcec2a6a/attachment-0003.html>


More information about the Chchrobotics mailing list