Makefile or IDE?

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?

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