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

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

Makefile or IDE?

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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#30936

On 04/12/2021 16:23, pozz wrote:
> 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 $@
> 

I almost never use makefiles that have the object files (or source
files, or other files) specified explicitly.

CFILES := $(foreach dir,$(ALLSOURCEDIRS),$(wildcard $(dir)/*.c))
CXXFILES := $(foreach dir,$(ALLSOURCEDIRS),$(wildcard $(dir)/*.cpp))

OBJSsrc := $(CFILES:.c=.o) $(CXXFILES:.cpp=.o)
OBJS := $(addprefix $(OBJDIR), $(patsubst ../%,%,$(OBJSsrc)))

If there is a C or C++ file in the source tree, it is part of the
project.  Combined with automatic dependency resolution (for which I use
gcc with -M* flags) this means that the make for a project adapts
automatically whenever you add new source or header files, or change the
ones that are there.

> 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


When you have a dependency given after a |, gnu make will ensure that it
exists but does not care about its timestamp.  So here it will check if
the target directory is there before creating target/%.o, and if not it
will make it.  It probably doesn't matter much for directories, but it
can be useful in some cases to avoid extra work.

And use "mkdir -p" to make a directory including any other parts of the
path needed, and to avoid an error if the directory already exists.

> 
> A better approach is to use a dedicated rule for directories, but it's
> very complex and tricky[1].

The reference you gave is okay too.  Some aspects of advanced makefiles
/are/ complex and tricky, and can be hard to debug (look out for mixes
of spaces instead of tabs at the start of lines!)  But once you've got
them in place, you can re-use them in other projects.  And you can copy
examples like the reference you gave, rather than figuring it out yourself.

> 
> I think your approach is better, only because is much more
> understandable, not because is more efficient.
> 

My version is - IMHO - understandable /and/ efficient.

> 
>>> 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?
> 

The exact choice of -M flags depends on details of your setup.  I prefer
to have the dependency creation done as a separate step from the
compilation - it's not strictly necessary, but I have found it neater.
However, I use two -MT flags per dependency file.  One makes a rule for
the file.o dependency, the other is for the file.d dependency.  That
way, make knows when it has to re-build the dependency file.

> 
>>> Is cmake simpler to configure?
>>
>> CMake does one-configuration-per-invocation type builds like sketched
>> above, i.e. to build target1/Release and target1/Debug, you invoke CMake
>> on two different workspaces, once with -DCMAKE_BUILD_TYPE=Release and
>> once with -DCMAKE_BUILD_TYPE=Debug.
> 
> Yes, I was asking if the configuration file of CMake is simpler to write
> compared to a Makefile.
> 

I've only briefly looked at CMake.  It always looked a bit limited to me
- sometimes I have a variety of extra programs or steps to run (like a
Python script to pre-process files and generate extra C or header files,
or extra post-processing steps).  I also often need different compiler
flags for different parts of a project.  Perhaps it would work for what
I need and I just haven't read enough.

> 
> [1] https://ismail.badawi.io/blog/automatic-directory-creation-in-make/

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

#30937

On 4.12.21 18.41, David Brown wrote:
> On 04/12/2021 16:23, pozz wrote:
>> 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 $@
>>
> 
> I almost never use makefiles that have the object files (or source
> files, or other files) specified explicitly.
> 
> CFILES := $(foreach dir,$(ALLSOURCEDIRS),$(wildcard $(dir)/*.c))
> CXXFILES := $(foreach dir,$(ALLSOURCEDIRS),$(wildcard $(dir)/*.cpp))
> 
> OBJSsrc := $(CFILES:.c=.o) $(CXXFILES:.cpp=.o)
> OBJS := $(addprefix $(OBJDIR), $(patsubst ../%,%,$(OBJSsrc)))
> 
> If there is a C or C++ file in the source tree, it is part of the
> project.  Combined with automatic dependency resolution (for which I use
> gcc with -M* flags) this means that the make for a project adapts
> automatically whenever you add new source or header files, or change the
> ones that are there.
> 
>> 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
> 
> 
> When you have a dependency given after a |, gnu make will ensure that it
> exists but does not care about its timestamp.  So here it will check if
> the target directory is there before creating target/%.o, and if not it
> will make it.  It probably doesn't matter much for directories, but it
> can be useful in some cases to avoid extra work.
> 
> And use "mkdir -p" to make a directory including any other parts of the
> path needed, and to avoid an error if the directory already exists.
> 
>>
>> A better approach is to use a dedicated rule for directories, but it's
>> very complex and tricky[1].
> 
> The reference you gave is okay too.  Some aspects of advanced makefiles
> /are/ complex and tricky, and can be hard to debug (look out for mixes
> of spaces instead of tabs at the start of lines!)  But once you've got
> them in place, you can re-use them in other projects.  And you can copy
> examples like the reference you gave, rather than figuring it out yourself.
> 
>>
>> I think your approach is better, only because is much more
>> understandable, not because is more efficient.
>>
> 
> My version is - IMHO - understandable /and/ efficient.
> 
>>
>>>> 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?
>>
> 
> The exact choice of -M flags depends on details of your setup.  I prefer
> to have the dependency creation done as a separate step from the
> compilation - it's not strictly necessary, but I have found it neater.
> However, I use two -MT flags per dependency file.  One makes a rule for
> the file.o dependency, the other is for the file.d dependency.  That
> way, make knows when it has to re-build the dependency file.
> 
>>
>>>> Is cmake simpler to configure?
>>>
>>> CMake does one-configuration-per-invocation type builds like sketched
>>> above, i.e. to build target1/Release and target1/Debug, you invoke CMake
>>> on two different workspaces, once with -DCMAKE_BUILD_TYPE=Release and
>>> once with -DCMAKE_BUILD_TYPE=Debug.
>>
>> Yes, I was asking if the configuration file of CMake is simpler to write
>> compared to a Makefile.
>>
> 
> I've only briefly looked at CMake.  It always looked a bit limited to me
> - sometimes I have a variety of extra programs or steps to run (like a
> Python script to pre-process files and generate extra C or header files,
> or extra post-processing steps).  I also often need different compiler
> flags for different parts of a project.  Perhaps it would work for what
> I need and I just haven't read enough.
> 
>>
>> [1] https://ismail.badawi.io/blog/automatic-directory-creation-in-make/


CMake is on a different level than make. CMake aims to the realm of
autoconf, automake and friends. One of the supported tail-ends for
CMake is GNU make.

-- 

-TV

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

#30938

On 04/12/2021 17:49, Tauno Voipio wrote:
> On 4.12.21 18.41, David Brown wrote:
>> On 04/12/2021 16:23, pozz wrote:
>>> Il 04/12/2021 10:31, Stefan Reuther ha scritto:

>>>>> Is cmake simpler to configure?
>>>>
>>>> CMake does one-configuration-per-invocation type builds like sketched
>>>> above, i.e. to build target1/Release and target1/Debug, you invoke
>>>> CMake
>>>> on two different workspaces, once with -DCMAKE_BUILD_TYPE=Release and
>>>> once with -DCMAKE_BUILD_TYPE=Debug.
>>>
>>> Yes, I was asking if the configuration file of CMake is simpler to write
>>> compared to a Makefile.
>>>
>>
>> I've only briefly looked at CMake.  It always looked a bit limited to me
>> - sometimes I have a variety of extra programs or steps to run (like a
>> Python script to pre-process files and generate extra C or header files,
>> or extra post-processing steps).  I also often need different compiler
>> flags for different parts of a project.  Perhaps it would work for what
>> I need and I just haven't read enough.
>>
>>>
>>> [1] https://ismail.badawi.io/blog/automatic-directory-creation-in-make/
> 
> 
> CMake is on a different level than make. CMake aims to the realm of
> autoconf, automake and friends. One of the supported tail-ends for
> CMake is GNU make.
> 

Yes, I know.  The question is, could I (or the OP, or others) use CMake
to control their builds?  It doesn't really matter if the output is a
makefile, a ninja file, or whatever - it matters if it can do the job
better (for some value of "better") than a hand-written makefile.  I
suspect that for projects that fit into the specific patterns it
supports, it will be a good choice - for others, it will not.

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

#30939

On 4.12.21 19.23, David Brown wrote:
> On 04/12/2021 17:49, Tauno Voipio wrote:
>> On 4.12.21 18.41, David Brown wrote:
>>> On 04/12/2021 16:23, pozz wrote:
>>>> Il 04/12/2021 10:31, Stefan Reuther ha scritto:
> 
>>>>>> Is cmake simpler to configure?
>>>>>
>>>>> CMake does one-configuration-per-invocation type builds like sketched
>>>>> above, i.e. to build target1/Release and target1/Debug, you invoke
>>>>> CMake
>>>>> on two different workspaces, once with -DCMAKE_BUILD_TYPE=Release and
>>>>> once with -DCMAKE_BUILD_TYPE=Debug.
>>>>
>>>> Yes, I was asking if the configuration file of CMake is simpler to write
>>>> compared to a Makefile.
>>>>
>>>
>>> I've only briefly looked at CMake.  It always looked a bit limited to me
>>> - sometimes I have a variety of extra programs or steps to run (like a
>>> Python script to pre-process files and generate extra C or header files,
>>> or extra post-processing steps).  I also often need different compiler
>>> flags for different parts of a project.  Perhaps it would work for what
>>> I need and I just haven't read enough.
>>>
>>>>
>>>> [1] https://ismail.badawi.io/blog/automatic-directory-creation-in-make/
>>
>>
>> CMake is on a different level than make. CMake aims to the realm of
>> autoconf, automake and friends. One of the supported tail-ends for
>> CMake is GNU make.
>>
> 
> Yes, I know.  The question is, could I (or the OP, or others) use CMake
> to control their builds?  It doesn't really matter if the output is a
> makefile, a ninja file, or whatever - it matters if it can do the job
> better (for some value of "better") than a hand-written makefile.  I
> suspect that for projects that fit into the specific patterns it
> supports, it will be a good choice - for others, it will not.


I tried to use it for some raw-iron embedded programs. IMHO, CMake
belongs there more to the problem than solution set. CMake is aimed
to produce code for the system it is run on, cross-compilation creates
problems.

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.

-- 

-TV

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

#30943

On 04/12/2021 20:25, Tauno Voipio wrote:
> On 4.12.21 19.23, David Brown wrote:
>> On 04/12/2021 17:49, Tauno Voipio wrote:
>>> On 4.12.21 18.41, David Brown wrote:
>>>> On 04/12/2021 16:23, pozz wrote:
>>>>> Il 04/12/2021 10:31, Stefan Reuther ha scritto:
>>
>>>>>>> Is cmake simpler to configure?
>>>>>>
>>>>>> CMake does one-configuration-per-invocation type builds like sketched
>>>>>> above, i.e. to build target1/Release and target1/Debug, you invoke
>>>>>> CMake
>>>>>> on two different workspaces, once with -DCMAKE_BUILD_TYPE=Release and
>>>>>> once with -DCMAKE_BUILD_TYPE=Debug.
>>>>>
>>>>> Yes, I was asking if the configuration file of CMake is simpler to
>>>>> write
>>>>> compared to a Makefile.
>>>>>
>>>>
>>>> I've only briefly looked at CMake.  It always looked a bit limited
>>>> to me
>>>> - sometimes I have a variety of extra programs or steps to run (like a
>>>> Python script to pre-process files and generate extra C or header
>>>> files,
>>>> or extra post-processing steps).  I also often need different compiler
>>>> flags for different parts of a project.  Perhaps it would work for what
>>>> I need and I just haven't read enough.
>>>>
>>>>>
>>>>> [1]
>>>>> https://ismail.badawi.io/blog/automatic-directory-creation-in-make/
>>>
>>>
>>> CMake is on a different level than make. CMake aims to the realm of
>>> autoconf, automake and friends. One of the supported tail-ends for
>>> CMake is GNU make.
>>>
>>
>> Yes, I know.  The question is, could I (or the OP, or others) use CMake
>> to control their builds?  It doesn't really matter if the output is a
>> makefile, a ninja file, or whatever - it matters if it can do the job
>> better (for some value of "better") than a hand-written makefile.  I
>> suspect that for projects that fit into the specific patterns it
>> supports, it will be a good choice - for others, it will not.
> 
> 
> I tried to use it for some raw-iron embedded programs. IMHO, CMake
> belongs there more to the problem than solution set. CMake is aimed
> to produce code for the system it is run on, cross-compilation creates
> problems.
> 
> 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.)

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

#30948

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

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

#30950

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.

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

#30951

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

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

#30954

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 $@

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

#30956

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.

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

#30957

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.)

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

#30959

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.

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

#30960

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!

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

#30961

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

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

#30963

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.

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

#30965

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.

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

#30958

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

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

#30962

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.

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

#30964

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

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

#30944

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.

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

>>> 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]

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

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

csiph-web