Yahoo Groups archive

AVR-Chat

Index last updated: 2026-04-28 22:41 UTC

Thread

OT - managing multi-target projects (linux/NGW)

OT - managing multi-target projects (linux/NGW)

2011-11-24 by Mark Nowell

Can anyone here give me any pointers as to how to elegantly manage 
multi-target source/binary structures? We're switching from NGW100 to a 
similar ARM-based board but need to continue building for the NGW, plus 
we do a lot of initial coding/test wholly on PC/linux. We currently have 
one source tree and whenever we want to build for a specific target we 
effectively do: make clean ; make -target. Is there a way to drive 
make/gcc which allows the object files and binaries for different 
targets to be kept alongside each other?
TIA,
Mark

Re: [AVR-Chat] OT - managing multi-target projects (linux/NGW)

2011-11-24 by Bob Paddock

> Can anyone here give me any pointers as to how to elegantly manage
> multi-target source/binary structures?

I do this a lot.  What you want to do is set up several small project
specific Makefiles,
for example ProjectA.mak and ProjectB.mak .

These contain the source files names, a target directory, and
configuration options.

These small project Makefiles then call a single Makefile.mak that
does the real work.

See this for an example, that answers your question in detail:

http://blog.softwaresafety.net/2010/08/building-product-variations-without.html

Today my Makefiles  make use of vpath to point to the source code.

I'm working on a series of Makefile tips:

http://blog.softwaresafety.net/2011/03/make-makefile-tip-4-gnu-make-standard.html
Tip #4
http://blog.softwaresafety.net/2010/09/transforming-files-with-wildcards-in.html
Tip #3
http://blog.softwaresafety.net/2010/09/recursive-use-of-make-makefile-tip-2.html
Tip #2
http://blog.softwaresafety.net/2010/08/building-product-variations-without.html
Tip #1
http://blog.softwaresafety.net/2010/08/automatic-serial-number-for-test-driven.html
Tip #0

I've got at least two more tips to add.  How to get the target
directory structure automatically generated, and how to use 'if' to
set paths of the build machine.

For the latter something like this, on a Windows machine:

ifeq ($(COMPUTERNAME),C655-20101219)
	cp $(OBJDIR)/$(TARGET).flash.bin C:/Projects/FirmwareUpdater/Firmware
endif

On a Linux box make use of uname.

For the former:

# In GNU Make 3.81 there's an exciting new feature called 'second
# expansion' (which is enabled by specifying the .SECONDEXPANSION
# target in the Makefile).  With second expansion the prerequisite
# list of any rule under goes a second expansion (the first expansion
# happens when the Makefile is read) just before the rule is used.  By
# escaping any $ signs with a second $ it's possible to use GNU Make
# automatic variables in the prerequisite list.
# We use this to build the empty directory structure if it does not exist.
# See the @D rules later in this file.

.SECONDEXPANSION:

%/.keep:
	mkdir -p $(dir $@)
	touch $@

.PRECIOUS: %/.keep

# The pattern rule used to make .o files has a special prerequisite
# $$(@D)/.keep which uses the second expansion feature to obtain the
# directory in which the target (from $@ using the D modifier) is to
# be built.
# See http://www.cmcrossroads.com/ask-mr-make/6936-making-directories-in-gnu-make

--
http://blog.softwaresafety.net/
http://www.designer-iii.com/
http://www.wearablesmartsensors.com/

Re: OT - managing multi-target projects (linux/NGW)

2011-11-24 by Don Kinzer

--- In AVR-Chat@yahoogroups.com, Mark Nowell <mark@...> wrote:
> Is there a way to drive make/gcc which allows the object files
> and binaries for different targets to be kept alongside each other?
We build for dozens of targets using the same code base, putting object files, libraries and executables in separate directories and/or with distinguishing names.  For example, when building for the mega644P the object files end up as objDir/mega644P/xxx.o and the libraries end up as libDir/libxxx_mega644P.a.  The makefile is set up to create the directories it needs if they don't already exist.  This makes it easy to effectively to a "make clean" for all targets by simply deleting the libDir and objDir directories.

I've created an outline of a makefile that uses these concepts that may give you some ideas.  I may have made some mistakes when I put this together but you should be able to understand the general idea.  You may need to consult the gnu make documentation for a fuller understanding.

http://www.zbasic.net/download/makefile.txt

For some of our projects we use recursive invocation of make (specifying values for certain macro names to control the operation) or we use separate makefiles (a.mak, b.mak, etc.) or a combination of both.  Which to use depends on the circumstances and goals.

Don Kinzer
ZBasic Microcontrollers

Re: [AVR-Chat] Re: OT - managing multi-target projects (linux/NGW)

2011-11-28 by Mark Nowell

Don and Bob,
Thanks very much for your help on this. I've had a look through the 
material you've provided and I'm sure the answers are in there - I can 
indeed see the general ideas but I need to find time to get to grips 
with some of the makefile usage, some of which are outside my limited 
subset, including vpath.
Thanks again,
Mark
Show quoted textHide quoted text
On 24/11/2011 17:55, Don Kinzer wrote:
>
> --- In AVR-Chat@yahoogroups.com, Mark Nowell<mark@...>  wrote:
>> Is there a way to drive make/gcc which allows the object files
>> and binaries for different targets to be kept alongside each other?
> We build for dozens of targets using the same code base, putting object files, libraries and executables in separate directories and/or with distinguishing names.  For example, when building for the mega644P the object files end up as objDir/mega644P/xxx.o and the libraries end up as libDir/libxxx_mega644P.a.  The makefile is set up to create the directories it needs if they don't already exist.  This makes it easy to effectively to a "make clean" for all targets by simply deleting the libDir and objDir directories.
>
> I've created an outline of a makefile that uses these concepts that may give you some ideas.  I may have made some mistakes when I put this together but you should be able to understand the general idea.  You may need to consult the gnu make documentation for a fuller understanding.
>
> http://www.zbasic.net/download/makefile.txt
>
> For some of our projects we use recursive invocation of make (specifying values for certain macro names to control the operation) or we use separate makefiles (a.mak, b.mak, etc.) or a combination of both.  Which to use depends on the circumstances and goals.
>
> Don Kinzer
> ZBasic Microcontrollers
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.