<div dir="ltr"><div>Another thing worth considering is dropping the notdir bit.</div><div><br></div><div>OBJECTS = $(addprefix $(BUILD_DIR)/,$(C_SOURCES:.c=.o))</div><div><br></div><div>That will mean you get the objects created in the same directory structure under the build to prevent file names from stomping on eachother.</div><div><br></div><div>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.</div><div><br></div><div>Example here:</div><div><a href="http://www.aleph1.co.uk/gitweb/?p=yaffs2.git;a=blob;f=direct/test-framework/tests/Makefile">http://www.aleph1.co.uk/gitweb/?p=yaffs2.git;a=blob;f=direct/test-framework/tests/Makefile</a></div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 3, 2020 at 6:32 PM Volker Kuhlmann <<a href="mailto:list57@top.geek.nz">list57@top.geek.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon 03 Aug 2020 16:54:17 NZST +1200, Robin Gilks wrote:<br>
<br>
[Makefile for different projects]<br>
<br>
I've done fairly extensive Makefile construction, but haven't had to<br>
make major changes in a while. I can see 2 approaches here:<br>
<br>
1) Share a Makefile<br>
<br>
Use shell globs to create the sources list, and run the Makefile in the<br>
project directory.<br>
<br>
Alternatively, use static sources lists, but then you'll have to assign<br>
variables dependent on the currently active target. It works, but can<br>
get a bit unpredicted because IIRC the assignments were not<br>
hierarchical, i.e. when a sub-target is made, the assignment disappears.<br>
Using both immediate and deferred variable assignments cleverly might<br>
help.<br>
<br>
I'm not sure having the same Makefile for when you add projects later is<br>
a good approach. Makefile changes for projectB might change the build of<br>
projectA.<br>
<br>
2) Have a Makefile per project<br>
<br>
This is usually the done thing. You can place the not-changing bulk of<br>
your Makefile into common, and use include. That's what I do. Make a<br>
template Makefile and include everything but the differences for this<br>
project. Parameterisation is good.<br>
<br>
You could add a top-level Makefile that makes all in subdirectories.<br>
<br>
If however your projects are different build variants (I have that<br>
lots), suitable parameterisation should do wonders.<br>
<br>
<br>
Always use implicit rules. As soon as you have explicit rules, things<br>
get complicated. The exception is where your explicit rules are<br>
automatically generated. There's a gcc option to auto-create the<br>
dependency list for each module. That's a good one to use too.<br>
<br>
<br>
Or did I misunderstand your requirements?<br>
<br>
Volker<br>
<br>
-- <br>
Volker Kuhlmann<br>
<a href="http://volker.top.geek.nz/" rel="noreferrer" target="_blank">http://volker.top.geek.nz/</a>      Please do not CC list postings to me.<br>
<br>
_______________________________________________<br>
Chchrobotics mailing list <a href="mailto:Chchrobotics@lists.ourshack.com" target="_blank">Chchrobotics@lists.ourshack.com</a><br>
<a href="https://lists.ourshack.com/mailman/listinfo/chchrobotics" rel="noreferrer" target="_blank">https://lists.ourshack.com/mailman/listinfo/chchrobotics</a><br>
Mail Archives: <a href="http://lists.ourshack.com/pipermail/chchrobotics/" rel="noreferrer" target="_blank">http://lists.ourshack.com/pipermail/chchrobotics/</a><br>
Meetings usually 3rd Monday each month. See <a href="http://kiwibots.org" rel="noreferrer" target="_blank">http://kiwibots.org</a> for venue, directions and dates.<br>
When replying, please edit your Subject line to reflect new subjects.</blockquote></div>