Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.arch.embedded > #30922 > unrolled thread

Makefile or IDE?

Started bypozz <pozzugno@gmail.com>
First post2021-12-02 12:46 +0100
Last post2021-12-21 10:55 -0800
Articles 9 on this page of 49 — 14 participants

Back to article view | Back to comp.arch.embedded


Contents

  Makefile or IDE? pozz <pozzugno@gmail.com> - 2021-12-02 12:46 +0100
    Re: Makefile or IDE? Grant Edwards <invalid@invalid.invalid> - 2021-12-02 15:22 +0000
      Re: Makefile or IDE? pozz <pozzugno@gmail.com> - 2021-12-02 17:34 +0100
        Re: Makefile or IDE? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2021-12-03 13:15 +0200
    Re: Makefile or IDE? Don Y <blockedofcourse@foo.invalid> - 2021-12-02 09:48 -0700
    Re: Makefile or IDE? Stefan Reuther <stefan.news@arcor.de> - 2021-12-02 17:34 +0100
      Re: Makefile or IDE? pozz <pozzugno@gmail.com> - 2021-12-03 11:49 +0100
        Re: Makefile or IDE? Stefan Reuther <stefan.news@arcor.de> - 2021-12-03 18:27 +0100
      Re: Makefile or IDE? George Neuner <gneuner2@comcast.net> - 2021-12-04 14:37 -0500
    Re: Makefile or IDE? Theo <theom+news@chiark.greenend.org.uk> - 2021-12-03 20:51 +0000
      Re: Makefile or IDE? Grant Edwards <invalid@invalid.invalid> - 2021-12-03 21:28 +0000
        Re: Makefile or IDE? George Neuner <gneuner2@comcast.net> - 2021-12-04 14:53 -0500
          Re: Makefile or IDE? David Brown <david.brown@hesbynett.no> - 2021-12-04 22:17 +0100
            Re: Makefile or IDE? Stefan Reuther <stefan.news@arcor.de> - 2021-12-05 11:02 +0100
              Re: Makefile or IDE? David Brown <david.brown@hesbynett.no> - 2021-12-05 13:16 +0100
          Re: Makefile or IDE? Grant Edwards <invalid@invalid.invalid> - 2021-12-06 13:52 +0000
            Re: Makefile or IDE? chris <chris-nospam@tridac.net> - 2021-12-17 17:19 +0000
    Re: Makefile or IDE? pozz <pozzugno@gmail.com> - 2021-12-03 23:48 +0100
      Re: Makefile or IDE? Stefan Reuther <stefan.news@arcor.de> - 2021-12-04 10:31 +0100
        Re: Makefile or IDE? pozz <pozzugno@gmail.com> - 2021-12-04 16:23 +0100
          Re: Makefile or IDE? David Brown <david.brown@hesbynett.no> - 2021-12-04 17:41 +0100
            Re: Makefile or IDE? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2021-12-04 18:49 +0200
              Re: Makefile or IDE? David Brown <david.brown@hesbynett.no> - 2021-12-04 18:23 +0100
                Re: Makefile or IDE? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2021-12-04 21:25 +0200
                  Re: Makefile or IDE? David Brown <david.brown@hesbynett.no> - 2021-12-04 22:20 +0100
                    Re: Makefile or IDE? Grant Edwards <invalid@invalid.invalid> - 2021-12-06 13:51 +0000
                      Re: Makefile or IDE? David Brown <david.brown@hesbynett.no> - 2021-12-06 16:33 +0100
                        Re: Makefile or IDE? Grant Edwards <invalid@invalid.invalid> - 2021-12-06 16:02 +0000
            Re: Makefile or IDE? pozz <pozzugno@gmail.com> - 2021-12-09 11:54 +0100
              Re: Makefile or IDE? Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2021-12-10 18:35 +0100
                Re: Makefile or IDE? David Brown <david.brown@hesbynett.no> - 2021-12-10 19:44 +0100
                  Re: Makefile or IDE? pozz <pozzugno@gmail.com> - 2021-12-11 16:18 +0100
                    Re: Makefile or IDE? David Brown <david.brown@hesbynett.no> - 2021-12-11 17:06 +0100
                      Re: Makefile or IDE? Grant Edwards <invalid@invalid.invalid> - 2021-12-11 16:57 +0000
                  Re: Makefile or IDE? Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2021-12-11 18:53 +0100
                    Re: Makefile or IDE? David Brown <david.brown@hesbynett.no> - 2021-12-12 14:15 +0100
                Re: Makefile or IDE? Stefan Reuther <stefan.news@arcor.de> - 2021-12-11 10:01 +0100
                  Re: Makefile or IDE? Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2021-12-11 18:47 +0100
                    Re: Makefile or IDE? Stefan Reuther <stefan.news@arcor.de> - 2021-12-12 11:27 +0100
          Re: Makefile or IDE? Stefan Reuther <stefan.news@arcor.de> - 2021-12-05 11:11 +0100
            Re: Makefile or IDE? David Brown <david.brown@hesbynett.no> - 2021-12-05 13:21 +0100
    Re: Makefile or IDE? Dave Nadler <drn@nadler.com> - 2021-12-06 15:45 -0500
    Re: Makefile or IDE? pozz <pozzugno@gmail.com> - 2021-12-09 10:43 +0100
    Re: Makefile or IDE? Johann Klammer <klammerj@NOSPAM.a1.net> - 2021-12-10 09:30 +0100
    Re: Makefile or IDE? chris <chris-nospam@tridac.net> - 2021-12-17 17:27 +0000
      Re: Makefile or IDE? StateMachineCOM <statemachineguru@gmail.com> - 2021-12-20 17:18 -0800
        Re: Makefile or IDE? chris <chris-nospam@tridac.net> - 2021-12-21 16:45 +0000
        Re: Makefile or IDE? Jim Jackson <jj@franjam.org.uk> - 2021-12-21 17:40 +0000
          Re: Makefile or IDE? StateMachineCOM <statemachineguru@gmail.com> - 2021-12-21 10:55 -0800

Page 3 of 3 — ← Prev page 1 2 [3]


#30947

FromDavid Brown <david.brown@hesbynett.no>
Date2021-12-05 13:21 +0100
Message-ID<soiasv$q97$1@dont-email.me>
In reply to#30944
On 05/12/2021 11:11, Stefan Reuther wrote:
> Am 04.12.2021 um 16:23 schrieb pozz:
>> Il 04/12/2021 10:31, Stefan Reuther ha scritto:
>>> I'm not sure what you need order-only dependencies for. For a project
>>> like this, with GNU make I'd most likely just do something like
>>>
>>>      OBJ = file1.o module1/file2.o module2/file3.o
>>>      main: $(OBJ)
>>>           $(CC) -o $@ $(OBJ)
>>>      $(OBJ): %.o: $(SRCDIR)/%.c
>>>           mkdir $(dir $@)
>>>           $(CC) $(CFLAGS) -c $< -o $@
>>
>> 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.
> 
> (did I really forget the '-p'?)
> 
> The idea was that creating a directory and checking for its existence
> both require a path lookup, which is the expensive operation here.
> 

Checking for the path is not expensive - it is already necessary to have
the path details read from the filesystem (and therefore cached, even on
Windows) because you want to put a file in it.  So it is free.  "mkdir
-p" is also very cheap - it only needs to do something if the path does
not exist.  (Of course, on Windows starting any process takes time and
resources an order of magnitude or more greater than on *nix.)  It is
always nice to avoid unnecessary effort, as even small inefficiencies
add up if there are enough of them.  But there's no need to worry unduly
about the small things.

> When generating the Makefile with a script, it's easy to sneak a 100%
> matching directory creation dependency into any rule that needs it
> 
>      foo/bar.o: bar.c foo/.mark
>           ...
>      foo/.mark:
>           mkdir foo
> 

And it's easy to forget the "touch foo/.mark" command to make that work!

But that is completely unnecessary - make is perfectly capable of
working with a directory as a dependency and target (especially as an
order-only dependency).

>>>> Dependencies must be created as a side effect of compilation with
>>>> esoteric -M options for gcc.
>>>
>>> It's not too bad with sufficiently current versions.
>>>
>>>      CFLAGS += -MMD -MP
>>>      -include $(OBJ:.o=.d)
>>
>> Are you sure you don't need -MT too, to specify exactly the target rule?
> 
> Documentation says you are right, but '-MMD -MP' works fine for me so far...
> 
> 
>   Stefan
> 

[toc] | [prev] | [next] | [standalone]


#30952

FromDave Nadler <drn@nadler.com>
Date2021-12-06 15:45 -0500
Message-ID<solsq4$19e7$1@gioia.aioe.org>
In reply to#30922
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!

[toc] | [prev] | [next] | [standalone]


#30953

Frompozz <pozzugno@gmail.com>
Date2021-12-09 10:43 +0100
Message-ID<sosj3b$11t$1@dont-email.me>
In reply to#30922
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

[toc] | [prev] | [next] | [standalone]


#30955

FromJohann Klammer <klammerj@NOSPAM.a1.net>
Date2021-12-10 09:30 +0100
Message-ID<sov381$ap1$1@gioia.aioe.org>
In reply to#30922
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)

[toc] | [prev] | [next] | [standalone]


#30967

Fromchris <chris-nospam@tridac.net>
Date2021-12-17 17:27 +0000
Message-ID<spihat$ohr$1@gioia.aioe.org>
In reply to#30922
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


[toc] | [prev] | [next] | [standalone]


#30968

FromStateMachineCOM <statemachineguru@gmail.com>
Date2021-12-20 17:18 -0800
Message-ID<aac8bc2e-7eed-4a97-b1e9-fecf235d9dean@googlegroups.com>
In reply to#30967
Would anyone point me to a good Makefile template for building a simple embedded project with GNU-ARM?

[toc] | [prev] | [next] | [standalone]


#30969

Fromchris <chris-nospam@tridac.net>
Date2021-12-21 16:45 +0000
Message-ID<spt0b6$8lp$1@gioia.aioe.org>
In reply to#30968
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

[toc] | [prev] | [next] | [standalone]


#30970

FromJim Jackson <jj@franjam.org.uk>
Date2021-12-21 17:40 +0000
Message-ID<slrnss44bm.945.jj@iridium.wf32df>
In reply to#30968
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

[toc] | [prev] | [next] | [standalone]


#30971

FromStateMachineCOM <statemachineguru@gmail.com>
Date2021-12-21 10:55 -0800
Message-ID<adab0c92-aed4-4d94-aeab-a2c82bfb035fn@googlegroups.com>
In reply to#30970
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

[toc] | [prev] | [standalone]


Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.arch.embedded


csiph-web