On 2021-12-04, David Brown <david.brown@hesbynett.no> wrote:
>
>> I succeeded to use CMake for cross-compiling on PC Linux for Raspi OS
>> Linux, but the compiler identification for a raw metal target was not
>> happy when the trial compilation could not link a run file using the
>> Linux run file creation model.
>
> That is kind of what I thought. CMake sounds like a good solution if
> you want to make a program that compiles on Linux with native gcc, and
> also with MSVC on Windows, and perhaps a few other native build
> combinations. But it is not really suited for microcontroller builds as
> far as I can see. (Again, I haven't tried it much, and don't want to do
> it injustice by being too categorical.)

I use CMake for cross-compilation for microcontroller stuff. I don't
use it for my own code, but there are a few 3rd-party libraries that
use it, and I don't have any problems configuring it to use a cross
compiler.

--
Grant

On 2021-12-04, George Neuner <gneuner2@comcast.net> wrote:
> On Fri, 3 Dec 2021 21:28:54 -0000 (UTC), Grant Edwards
><invalid@invalid.invalid> wrote:
>
>>On 2021-12-03, Theo <theom+news@chiark.greenend.org.uk> wrote:
>>
>>> [*] Powershell and WSL have been trying to improve this. But I've not seen
>>> any build flows that make much use of them, beyond simply taking Linux flows
>>> and running them in WSL.
>>
>>I always had good luck using Cygwin and gnu "make" on Windows to run
>>various Win32 .exe command line compilers (e.g. IAR). I (thankfully)
>>haven't needed to do that for several years now...
>
> The problem with Cygwin is it doesn't play well with native Windows
> GCC (MingW et al).

It's always worked fine for me.

> Cygwin compilers produce executables that depend on the /enormous/
> Cygwin library.

I wasn't talking about using Cygwin compilers. I was talking about
using Cygwin to do cross-compilation using compilers like IAR.

> You can statically link the library or ship the DLL (or an installer
> that downloads it) with your program, but by doing so your programs
> falls under GPL - the terms of which are not acceptable to some
> developers.
>
> And the Cygwin environment is ... less than stable. Any update to
> Windows can break it.

That's definitely true. :/

On 06/12/2021 14:51, Grant Edwards wrote:
> On 2021-12-04, David Brown <david.brown@hesbynett.no> wrote:
>>
>>> I succeeded to use CMake for cross-compiling on PC Linux for Raspi OS
>>> Linux, but the compiler identification for a raw metal target was not
>>> happy when the trial compilation could not link a run file using the
>>> Linux run file creation model.
>>
>> That is kind of what I thought. CMake sounds like a good solution if
>> you want to make a program that compiles on Linux with native gcc, and
>> also with MSVC on Windows, and perhaps a few other native build
>> combinations. But it is not really suited for microcontroller builds as
>> far as I can see. (Again, I haven't tried it much, and don't want to do
>> it injustice by being too categorical.)
>
> I use CMake for cross-compilation for microcontroller stuff. I don't
> use it for my own code, but there are a few 3rd-party libraries that
> use it, and I don't have any problems configuring it to use a cross
> compiler.
>

OK. As I said, I haven't looked in detail or tried much. Maybe I will,
one day when I have time.

On 2021-12-06, David Brown <david.brown@hesbynett.no> wrote:
> On 06/12/2021 14:51, Grant Edwards wrote:

>> I use CMake for cross-compilation for microcontroller stuff. I don't
>> use it for my own code, but there are a few 3rd-party libraries that
>> use it, and I don't have any problems configuring it to use a cross
>> compiler.
>
> OK. As I said, I haven't looked in detail or tried much. Maybe I will,
> one day when I have time.

I see no reason at all to use for embedded code unless you want to use
a large 3rd party library that already uses it, and you want to use
that library's existing cmake build process. For smaller libraries,
it's probably easier to write a makefile from scratch.

IMO, configuring stuff that uses cmake seems very obtuse and fragile —
but that's probably because I don't use it much.

--
Grant

On 12/2/2021 6:46 AM, pozz wrote:
> When I download C source code (for example for Linux), most of the time
> I need to use make (or autoconf).
>
> In embedded world (no Linux embedded), we use MCUs produced by a silicon
> vendor that give you at least a ready-to-use IDE (Elipse based or Visual
> Studio based or proprietary). Recently it give you a full set of
> libraries, middlewares, tools to create a complex project from scratch
> in a couple of minutes that is compatibile and buildable with its IDE.
>
> Ok, it's a good thing to start with a minimal effort and make some tests
> on EVB and new chips. However I'm wondering if a good quality
> commercial/industrial grade software is maintained under the IDE of the
> silicon vendor or it is maintained with a Makefile (or similar).
>
> I'm asking this, because I just started to add some unit tests (to run
> on the host machine) on one of my projects that is built under the IDE.
> Without a Makefile is very difficult to add a series of tests: do I
> create a different IDE project for each module test?
>
> Moreover, the build process of a project maintained under an IDE is
> manual (click on a button). Most of the time there isn't the possibility
> to build by a command line and when it is possible, it isn't the
> "normal" way.
>
> Many times in the past I tried to write a Makefile for my projects, but
> sincerely for me make tool is very criptic (tabs instead of spaces?).
> Dependencies are a mess.
>
> Do you use IDE or Makefile? Is there a recent and much better
> alternative to make (such as cmake or SCons)?

For my most recent projects, I'm using Eclipse and letting it generate
the make files. I find it necessary to manually clean up the XML
controlling Eclipse to ensure that there are no hard-coded paths and
everything uses sane path variables (after starting with
vendor-tool-generated project).

I have multiple projects in the workspace:
1) target project uses the GCC ARM cross-compiler (debug and release
targets), and
2) for host builds of debug+test software, one or more minGW GCC projects

Its not optimal but it does work without too much grief.
Does a poor job for understanding/maintaining those places where
different compiler options are needed (fortunately not many).

I read *the* book on CMake and my head hurts, plus the book is revised
every three weeks as CMake adds or fixes numerous 'special' things.
Haven't actually used it yet but might try (with Zephyr).

My older big projects are primarily make (with dozens of targets
including intermediate preprocess stuff), plus separate Visual Studio
build for a simulator, an Eclipse build (auto-generated make) for one of
the embedded components, and Linux Eclipse build (auto-generated make)
for Linux versions of utilities. All this is painful to maintain and
keep synchronized. Sure would like to see a better way to handle all the
different targets and platforms (which CMake should help with but I'm
really not sure how to wrangle the thing).

Interesting discussion!

Il 02/12/2021 12:46, pozz ha scritto:
[...]
> Do you use IDE or Makefile? Is there a recent and much better
> alternative to make (such as cmake or SCons)?

I reply to this post for a few questions on make.

For embedded projects, we use at least one cross-compiler. I usually use
two compilers: cross-compiler for the embedded target and
native-compiler for creating a "simulator" for the host or for running
some tests on the host.

I'm thinking to use an env variable to choose between the targets:

make TARGET=embedded|host

If the native compiler is usually already on the PATH (even if I prefer
to avoid), cross-compiler is usually not already in the PATH. How do you
solve this?

I'm thinking to use again env variables and set them in a batch script
path.bat that is machine dependent (so it shouldn't be tracked by git).

SET GNU_ARM=c:\nxp\MCUXpressoIDE_11.2.1_4149...
SET MINGW_PATH=c:\mingw64

In the makefile:

ifeq($(TARGET),embedded)
CC := "$(GNU_ARM)/bin/arm-none-eabi-gcc"
CPP...
else ifeq($(TARGET),host)
CC := $(MINGW_PATH)/bin/gcc
CPP...
endif

In this way, I launch path.bat only one time on my windows development
machine and run make TARGET= during development.

Another issue is with internal commands of cmd.exe. GNU make for
Windows, ARM gcc, mingw and so on are able to manage paths with
Unix-like slash, but Windows internal commands such as mkdir, del does not.
I think it's much better to use Unix like commands (mkdir, rm) that can
be installed with coreutils[1] for Windows.

So in path.bat I add the coreutils folder to PATH:

SET COREUTILS_PATH=C:\TOOLS\COREUTILS

and in Makefile:

MKDIR := $(COREUTILS_PATH)/bin/mkdir
RM := $(COREUTILS_PATH)/bin/rm

Do you use better solutions?

[1] http://gnuwin32.sourceforge.net/packages/coreutils.htm

Il 04/12/2021 17:41, David Brown ha scritto:
[...]
>> This is suboptimal. Every time one object file is created (because it is
>> not present or because prerequisites aren't satisfied), mkdir command is
>> executed, even if $(dir $@) is already created.
>
> Use existence-only dependencies:
>
> target/%.o : %.c | target
> $(CC) $(CFLAGS) -c $< -o $@
>
> target :
> mkdir -p target

Do you replicate the source tree in the target directory for build?

I'd prefer to have the same tree in source and build dirs:

src/
file1.c
mod1/
file1.c
mod2/
file1.c
build/
file1.o
mod1/
file1.o
mod2/
file1.o

With your rules above, I don't think this can be done. target is only
the main build directory, but I need to create subdirectories too.

I understood for this I need to use $(@D) in prerequisites and this can
be done only with second expansion.

..SECONDEXPANSION:

target/%.o : %.c target/%.d | $$(@D)
$(CC) $(CFLAGS) -c $< -o $@

$(BUILD_DIRS):
$(MKDIR) -p $@

On 12/02/2021 12:46 PM, pozz wrote:
>
> Do you use IDE or Makefile? Is there a recent and much better alternative to make (such as cmake or SCons)?
>
Whatever will run on your box.(usually that's make/automake and nothing else)

Am 09.12.2021 um 11:54 schrieb pozz:

> I'd prefer to have the same tree in source and build dirs:

What on earth for?

Subdirectories for sources are necessary to organize our work, because
humans can't deal too well with folders filled with hundreds of files,
and because we fare better with the project's top-down structure
tangibly represented as a tree of subfolders.

But let's face it: we very rarely even look at object files, much less
work on them in any meaningful fashion. They just have to be somewhere,
but it's no particular burden at all if they're all in a single folder,
per primary build target. They're for the compiler and make alone to
work on, not for humans. So they don't have to be organized for human
consumption.

That's why virtually all hand-written Makefiles I've ever seen, and a
large portion of the auto-generated ones, too, keep all of a target's
object, list and dependency files in a single folder. Mechanisms like
VPATH exist for the express purpose of easing this approach, and the
built-in rules and macros also largely rely on it.

The major exception in this regard is CMake, which does indeed mirror
the source tree layout --- but that's manageable for them only because
their Makefiles, being fully machine-generated, can become almost
arbitrarily complex, for no extra cost. Nobody in full possession of
their mental capabilities would ever write Makefiles the way CMake does
it, by hand.

On 10/12/2021 18:35, Hans-Bernhard Bröker wrote:
> Am 09.12.2021 um 11:54 schrieb pozz:
>
>> I'd prefer to have the same tree in source and build dirs:
>
> What on earth for?
>
> Subdirectories for sources are necessary to organize our work, because
> humans can't deal too well with folders filled with hundreds of files,
> and because we fare better with the project's top-down structure
> tangibly represented as a tree of subfolders.
>
> But let's face it: we very rarely even look at object files, much less
> work on them in any meaningful fashion.  They just have to be somewhere,
> but it's no particular burden at all if they're all in a single folder,
> per primary build target.  They're for the compiler and make alone to
> work on, not for humans.  So they don't have to be organized for human
> consumption.
>
> That's why virtually all hand-written Makefiles I've ever seen, and a
> large portion of the auto-generated ones, too, keep all of a target's
> object, list and dependency files in a single folder.  Mechanisms like
> VPATH exist for the express purpose of easing this approach, and the
> built-in rules and macros also largely rely on it.
>
> The major exception in this regard is CMake, which does indeed mirror
> the source tree layout --- but that's manageable for them only because
> their Makefiles, being fully machine-generated, can become almost
> arbitrarily complex, for no extra cost.  Nobody in full possession of
> their mental capabilities would ever write Makefiles the way CMake does
> it, by hand.

There are other automatic systems that mirror the structure of the
source tree for object files, dependency files and list files (yes, some
people still like these). Eclipse does it, for example, and therefore
the majority of vendor-supplied toolkits since most are Eclipse based.
(I don't know if NetBeans and Visual Studio / Visual Studio Code do so -
these are the other two IDE's commonly used by manufacturer tools).

The big advantage of having object directories that copy source
directories is that it all works even if you have more than one file
with the same name. Usually, of course, you want to avoid name
conflicts - there are risks of other issues or complications such as
header guard symbols that are not unique (they /can/ include directory
information and not just the filename, but they don't always do so) and
you have to be careful that you #include the files you meant. But with
big projects containing SDK files, third-party libraries, RTOS's,
network stacks, and perhaps files written by many people working
directly on the project, conflicts happen. "timers.c" and "utils.c"
sound great to start with, but there is a real possibility of more than
one turning up in a project.

It is not at all hard to make object files mirror the source tree, and
it adds nothing to the build time. For large projects, it is clearly
worth the effort. (For small projects, it is probably not necessary.)

Am 10.12.2021 um 18:35 schrieb Hans-Bernhard Bröker:
> Am 09.12.2021 um 11:54 schrieb pozz:
>> I'd prefer to have the same tree in source and build dirs:
>
> What on earth for?
>
> Subdirectories for sources are necessary to organize our work, because
> humans can't deal too well with folders filled with hundreds of files,
> and because we fare better with the project's top-down structure
> tangibly represented as a tree of subfolders.
>
> But let's face it: we very rarely even look at object files, much less
> work on them in any meaningful fashion.  They just have to be somewhere,
> but it's no particular burden at all if they're all in a single folder,
> per primary build target.

But sometimes, we do look at them. Especially in an embedded context.
One example could be things like stack consumption analysis. Or to
answer the question "how much code size do I pay for using this C++
feature?". "Did the compiler correctly inline this function I expected
it to inline?".

And if the linker gives me a "duplicate definition" error, I prefer that
it is located in 'editor.o', not '3d3901cdeade62df1565f9616e607f89.o'.

> The major exception in this regard is CMake, which does indeed mirror
> the source tree layout --- but that's manageable for them only because
> their Makefiles, being fully machine-generated, can become almost
> arbitrarily complex, for no extra cost.  Nobody in full possession of
> their mental capabilities would ever write Makefiles the way CMake does
> it, by hand.

The main reason I'd never write Makefiles the way CMake does it is that
CMake's makefiles are horribly inefficient...

But otherwise, once you got infrastructure to place object files in SOME
subdirectory in your build system, mirroring the source structure is
easy and gives a usability win.

Stefan

Il 10/12/2021 19:44, David Brown ha scritto:
> On 10/12/2021 18:35, Hans-Bernhard Bröker wrote:
>> Am 09.12.2021 um 11:54 schrieb pozz:
>>
>>> I'd prefer to have the same tree in source and build dirs:
>>
>> What on earth for?
>>
>> Subdirectories for sources are necessary to organize our work, because
>> humans can't deal too well with folders filled with hundreds of files,
>> and because we fare better with the project's top-down structure
>> tangibly represented as a tree of subfolders.
>>
>> But let's face it: we very rarely even look at object files, much less
>> work on them in any meaningful fashion.  They just have to be somewhere,
>> but it's no particular burden at all if they're all in a single folder,
>> per primary build target.  They're for the compiler and make alone to
>> work on, not for humans.  So they don't have to be organized for human
>> consumption.
>>
>> That's why virtually all hand-written Makefiles I've ever seen, and a
>> large portion of the auto-generated ones, too, keep all of a target's
>> object, list and dependency files in a single folder.  Mechanisms like
>> VPATH exist for the express purpose of easing this approach, and the
>> built-in rules and macros also largely rely on it.
>>
>> The major exception in this regard is CMake, which does indeed mirror
>> the source tree layout --- but that's manageable for them only because
>> their Makefiles, being fully machine-generated, can become almost
>> arbitrarily complex, for no extra cost.  Nobody in full possession of
>> their mental capabilities would ever write Makefiles the way CMake does
>> it, by hand.
>
> There are other automatic systems that mirror the structure of the
> source tree for object files, dependency files and list files (yes, some
> people still like these). Eclipse does it, for example, and therefore
> the majority of vendor-supplied toolkits since most are Eclipse based.
> (I don't know if NetBeans and Visual Studio / Visual Studio Code do so -
> these are the other two IDE's commonly used by manufacturer tools).

Atmel Studio, now Microchip Studio, that is based on Visual Studio
mirrors exactly the source tree to the build dir.

> The big advantage of having object directories that copy source
> directories is that it all works even if you have more than one file
> with the same name. Usually, of course, you want to avoid name
> conflicts - there are risks of other issues or complications such as
> header guard symbols that are not unique (they /can/ include directory
> information and not just the filename, but they don't always do so) and
> you have to be careful that you #include the files you meant. But with
> big projects containing SDK files, third-party libraries, RTOS's,
> network stacks, and perhaps files written by many people working
> directly on the project, conflicts happen. "timers.c" and "utils.c"
> sound great to start with, but there is a real possibility of more than
> one turning up in a project.

Yes, these are the reasons why I'd like to put object files in
subdirectories.

> It is not at all hard to make object files mirror the source tree, and
> it adds nothing to the build time. For large projects, it is clearly
> worth the effort. (For small projects, it is probably not necessary.)

Ok, it's not too hard (nothing is hard when you know how to do it), but
it's not that simple too.

On 11/12/2021 16:18, pozz wrote:

>
> Ok, it's not too hard (nothing is hard when you know how to do it), but
> it's not that simple too.
>

Of course.

And once you've got a makefile you like for one project, you copy it for
the next. I don't think I have started writing a new makefile in 25 years!

On 2021-12-11, David Brown <david.brown@hesbynett.no> wrote:
> On 11/12/2021 16:18, pozz wrote:
>
>> Ok, it's not too hard (nothing is hard when you know how to do it), but
>> it's not that simple too.
>
> Of course.
>
> And once you've got a makefile you like for one project, you copy it for
> the next. I don't think I have started writing a new makefile in 25 years!

Too true.

You don't write a Makefile from scratch any more than you sit down
with some carbon, water, nitrogen, phosphorus and whatnot and make an
apple tree.

You look around and find an nice existing one that's closest to what
you want, copy it, and start tweaking.

--
Grant

Am 11.12.2021 um 10:01 schrieb Stefan Reuther:
> Am 10.12.2021 um 18:35 schrieb Hans-Bernhard Bröker:

>> But let's face it: we very rarely even look at object files, much less
>> work on them in any meaningful fashion.  They just have to be somewhere,
>> but it's no particular burden at all if they're all in a single folder,
>> per primary build target.
>
> But sometimes, we do look at them. Especially in an embedded context.

In my experience, looking at individual object files does not occur in
embedded context any more often than in others.

> One example could be things like stack consumption analysis.

That one's actually easier if you have the object files all in a single
folder, as the tool will have to look at all of them anyway, so it helps
if you can just pass it objdir/*.o.

Or to
> answer the question "how much code size do I pay for using this C++
> feature?". "Did the compiler correctly inline this function I expected
> it to inline?".

Both of those are way easier to check in the debugger or in the mapfile,
than by inspecting individual object files.

>
> And if the linker gives me a "duplicate definition" error, I prefer that
> it is located in 'editor.o', not '3d3901cdeade62df1565f9616e607f89.o'.

Both are equally useless. You want to know which source file they're in,
not which object files.

Do you actually use a tool that obfuscates the o file nimes like that?

> But otherwise, once you got infrastructure to place object files in SOME
> subdirectory in your build system, mirroring the source structure is
> easy and gives a usability win.

I don't think you've actually mentioned a single one, so far. None of
the things you mentioned had anything to do with _where_ the object
files are.

Am 10.12.2021 um 19:44 schrieb David Brown:

> The big advantage of having object directories that copy source
> directories is that it all works even if you have more than one file
> with the same name.

Setting aside the issue whether the build can actually handle that
("module names" in the code tend to only be based on the basename of the
source, not its full path, so they would clash anyway), that should
remain an exceptional mishap. I don't subscribe to the idea of making
my everyday life harder to account for (usually) avoidable exceptions
like that.

Am 11.12.2021 um 18:47 schrieb Hans-Bernhard Bröker:
> Am 11.12.2021 um 10:01 schrieb Stefan Reuther:
>> Am 10.12.2021 um 18:35 schrieb Hans-Bernhard Bröker:
>>> But let's face it: we very rarely even look at object files, much less
>>> work on them in any meaningful fashion.  They just have to be somewhere,
>>> but it's no particular burden at all if they're all in a single folder,
>>> per primary build target.
>>
>> But sometimes, we do look at them. Especially in an embedded context.
>
> In my experience, looking at individual object files does not occur in
> embedded context any more often than in others.

Neither in my experience, but this is because I look at individual
object files even for desktop/server applications, but I don't expect
that to be the rule :)

>> Or to
>> answer the question "how much code size do I pay for using this C++
>> feature?". "Did the compiler correctly inline this function I expected
>> it to inline?".
>
> Both of those are way easier to check in the debugger or in the mapfile,
> than by inspecting individual object files.

For me, 'objdump -dr blah.o | less' or 'nm blah.o | awk ...' is the
easiest way to answer such questions. The output of 'objdump | less' is
much easier to handle than gdb's 'disas'. And how do you even get
function sizes with a debugger?

>> And if the linker gives me a "duplicate definition" error, I prefer that
>> it is located in 'editor.o', not '3d3901cdeade62df1565f9616e607f89.o'.
>
> Both are equally useless. You want to know which source file they're in,
> not which object files.

I want to know in what translation unit they are in. It doesn't help to
know that the duplicate definition comes from 'keys.inc' which is
supposed to be included exactly once. I want to know which two
translation units included it, and for that it helps to have the name of
the translation unit - the initial *.c/cpp file - encoded in the object
file name.

> Do you actually use a tool that obfuscates the o file nimes like that?

Encoding the command-line that generates a file (as a cryptographic
hash) into the file name is a super-easy way to implement
rebuild-on-rule-change. I use that for a number of temporary files.

I do not use that for actual object files for the reasons given, but it
would technically make sense.

> I don't think you've actually mentioned a single one, so far.  None of
> the things you mentioned had anything to do with _where_ the object
> files are.

There are no hard technical reasons. It's all about usability, and
that's about the things you actually do. If you got a GUI that takes you
to the assembler code of a function with a right-click in the editor,
you don't need 'objdump'. I don't have such a GUI and don't want it most
of the time.

Stefan

On 11/12/2021 18:53, Hans-Bernhard Bröker wrote:
> Am 10.12.2021 um 19:44 schrieb David Brown:
>
>> The big advantage of having object directories that copy source
>> directories is that it all works even if you have more than one file
>> with the same name. 
>
> Setting aside the issue whether the build can actually handle that
> ("module names" in the code tend to only be based on the basename of the
> source, not its full path, so they would clash anyway), that should
> remain an exceptional mishap.  I don't subscribe to the idea of making
> my everyday life harder to account for (usually) avoidable exceptions
> like that.
>

Nor do I. But as I said, and as others know, supporting object files in
a tree is not difficult in a makefile, and it is common practice for
many build systems. I can't think of any that /don't/ support it (not
that I claim to have used a sizeable proportion of build systems).

If it is easy to avoid a particular class of problem, and have a nice,
neat structure, then what's the problem with having object files in a tree?

After all, the basic principle of an automatically maintained makefile
(or other build system) is:

1. Find all the source files - src/x/y/z.c - in whatever source paths
you have specified.

2. Determine all the object files you need by swapping ".c" for ".o",
and changing the "src" directory for the "build" directory, giving you a
list build/x/y/z.o.

3. Figure out a set of dependency rules for these, either using
something like "gcc -M...", or the lazy method of making all object
files depend on all headers, or something inbetween.

4. Make your binary file depend on all the build/x/y/z.o files.

As I see it, it is simpler, clearer and more natural that the object
files (and dependencies, lists files, etc.) follow the structure of the
source files. I'd have to go out of my way to make a riskier system
that put all the object files in one place.

On 12/06/21 13:52, Grant Edwards wrote:
> On 2021-12-04, George Neuner<gneuner2@comcast.net> wrote:
>> On Fri, 3 Dec 2021 21:28:54 -0000 (UTC), Grant Edwards
>> <invalid@invalid.invalid> wrote:
>>
>>> On 2021-12-03, Theo<theom+news@chiark.greenend.org.uk> wrote:
>>>
>>>> [*] Powershell and WSL have been trying to improve this. But I've not seen
>>>> any build flows that make much use of them, beyond simply taking Linux flows
>>>> and running them in WSL.
>>>
>>> I always had good luck using Cygwin and gnu "make" on Windows to run
>>> various Win32 .exe command line compilers (e.g. IAR). I (thankfully)
>>> haven't needed to do that for several years now...
>>
>> The problem with Cygwin is it doesn't play well with native Windows
>> GCC (MingW et al).
>
> It's always worked fine for me.
>
>> Cygwin compilers produce executables that depend on the /enormous/
>> Cygwin library.
>
> I wasn't talking about using Cygwin compilers. I was talking about
> using Cygwin to do cross-compilation using compilers like IAR.
>
>> You can statically link the library or ship the DLL (or an installer
>> that downloads it) with your program, but by doing so your programs
>> falls under GPL - the terms of which are not acceptable to some
>> developers.
>>
>> And the Cygwin environment is ... less than stable. Any update to
>> Windows can break it.
>
> That's definitely true. :/
>

Used cygwin for years just to have access to the unix utils and X
so I could run my favourite nedit fs editor, Never ran compilers
though it, but hassle free experience once setup. That was the 32 bit
version, sadly no longer available...

Chris

On 12/02/21 11:46, pozz wrote:
> When I download C source code (for example for Linux), most of the time
> I need to use make (or autoconf).
>
> In embedded world (no Linux embedded), we use MCUs produced by a silicon
> vendor that give you at least a ready-to-use IDE (Elipse based or Visual
> Studio based or proprietary). Recently it give you a full set of
> libraries, middlewares, tools to create a complex project from scratch
> in a couple of minutes that is compatibile and buildable with its IDE.
>
> Ok, it's a good thing to start with a minimal effort and make some tests
> on EVB and new chips. However I'm wondering if a good quality
> commercial/industrial grade software is maintained under the IDE of the
> silicon vendor or it is maintained with a Makefile (or similar).
>
> I'm asking this, because I just started to add some unit tests (to run
> on the host machine) on one of my projects that is built under the IDE.
> Without a Makefile is very difficult to add a series of tests: do I
> create a different IDE project for each module test?
>
> Moreover, the build process of a project maintained under an IDE is
> manual (click on a button). Most of the time there isn't the possibility
> to build by a command line and when it is possible, it isn't the
> "normal" way.
>
> Many times in the past I tried to write a Makefile for my projects, but
> sincerely for me make tool is very criptic (tabs instead of spaces?).
> Dependencies are a mess.
>
> Do you use IDE or Makefile? Is there a recent and much better
> alternative to make (such as cmake or SCons)?
>

Have a standard Makefile template that gets edited for each new project
or part thereof.

IDE systems may have their attractions, but usually don't like their
editors, nor the plethora of config files. The more plain vanilla the
better here, hence makefiles as the least hassle and most productive
route. Need to have full visibility from top to bottom and some ide's
can be pretty opaque.

Older versions of netbeans looked interesting though...

Chris

Would anyone point me to a good Makefile template for building a simple embedded project with GNU-ARM?

On 12/21/21 01:18, StateMachineCOM wrote:
> Would anyone point me to a good Makefile template for building a simple embedded project with GNU-ARM?

I'm sure they must exist but perhaps most generate their own. Look
at how others have done it, but the key is to keep it simple to
start. Define a root path for sources and subdirs. same for tools
and libraries. Then some simple rules to relate compiler to srcs
and objects. You only need to understand the make basics to get
started. The syntax is arcane and it can seem opaque in error
message terms, but you just have to persevere until you have
something working.

Here's a snippet from a makefile here nothing clever, but try
to abstract as much as possible to aid reuse. Like to keep it
neat and tidy, as this aids understanding and you only need
to do that once.

# Local Project Directories

ROOT = /export/nfs/sas8x600/system/projects/ntp-tests
PRJROOT = $(ROOT)/ntp-client

SRCDIR = $(PRJROOT)/src
INCDIR = $(PRJROOT)/inc
OBJDIR = $(PRJROOT)/obj
BINDIR = $(PRJROOT)/bin
LIBDIR = $(PRJROOT)/lib

# Library & Test Rig

PRJLIB = ntplib.a
PRJBIN = ntpbin

# Subsystem libraries and includes

SYSINC = $(ROOT)/sysinc
SYSLIB = $(ROOT)/syslib

# Tools

GCCROOT = /usr/local

GCCINC = $(GCCROOT)/include
GCCBIN = $(GCCROOT)/bin
GCCLIB = $(GCCROOT)/lib
GCCRTL = $(GCCLIB)/gcc/sparc-sun-solaris2.10/4.6.1

GCCOBJS = $(GCCRTL)/crt1.o $(GCCRTL)/crti.o $(GCCRTL)/crtbegin.o
$(GCCRTL)/crtend.o $(GCCRTL)/crtn.o

CC = $(GCCBIN)/gcc
CFLAGS = -c -O2 -ansi -Wall

AS = as
ASFLAGS =

LD = ld
LDFLAGS = -L/usr/local/lib/gcc/sparc-sun-solaris2.10/4.6.1
-R/usr/local/lib -lc -lsocket -s

AR = ar
ARFLAGS = crvs

INCLUDES = -I$(INCDIR) -I$(SYSINC)

#
# Dependency Search Paths
# vpath %.h $(INCDIR)
vpath %.c $(SRCDIR)
vpath %.o $(OBJDIR)

#
# Rules
# ..SUFFIXES:
..SUFFIXES: .c .o

..c.o:
$(CC) $(CFLAGS) $(INCLUDES) -c $(SRCDIR)/$< -o $(OBJDIR)/$@

# Network Function Library
# LIBINCS = network.h
LIBSRCS = network.c
LIBOBJS = network.o

# Executable Test Harness

SRCS = main.c network.c
OBJS = main.o network.o

# Default Target: Build Library and Test Harness
# default: $(LIBOBJS) $(OBJS) $(SRCS)
$(AR) $(ARFLAGS) $(LIBDIR)/$(PRJLIB) $(addprefix $(OBJDIR)/, $(LIBOBJS))
$(LD) $(LDFLAGS) $(OBJDIR)/main.o $(GCCOBJS) $(LIBDIR)/$(PRJLIB) -o
$(SRCDIR)/$(PRJBIN)
cp $(LIBDIR)/$(PRJLIB) $(SYSLIB)/$(PRJLIB)
cp $(addprefix $(INCDIR)/, $(LIBINCS)) $(SYSINC)

# Start Over...
# clean:
rm -f $(BINDIR)/$(PRJBIN) $(OBJDIR)/*.o $(LIBDIR)/$(PRJLIB)
$(SYSLIB)/$(PRJLIB) $(addprefix $(SYSINC)/, $(LIBINCS))

This wasn't for an embedded project, but nothing clever or obscure
and could probably be improved, so pull it to bits if you like...

Chris

On 2021-12-21, StateMachineCOM <statemachineguru@gmail.com> wrote:
> Would anyone point me to a good Makefile template for building a
> simple embedded project with GNU-ARM?

I've used this one ...

https://mithatkonar.com/wiki/doku.php/microcontrollers/avr_makefile_template

Thanks a lot for the suggestions. I'll study them carefully,

I'm already using a homegrown Makefile "template", such as this one:

https://github.com/QuantumLeaps/qpc/blob/master/examples/arm-cm/blinky_ek-tm4c123gxl/qk/gnu/Makefile

The Makefile supports multiple build configurations (Debug, Release, and "Spy" with software tracing), generation of dependencies, etc.. It is pretty straightforward with all source files, directories and libraries configurable. The Makefile uses VPATH to simplify the search for the sources. This really simplifies things, but requires unique file names for sources.

I'm not sure if this Makefile looks "professional" enough to experts. Any constructive critique and suggestions for improvement will be welcome.

Miro