I need a little assistance to move up the `make' learning curve.

I have been using `make' for ages, but my Makefiles are simple in the
sense that all the files have always resided in the same directory.

I have a new project, however, which will contain its component files
(lots of 'em) at 2 or 3 levels, under the same top directory.

Before I start experimenting, perhaps some of the experts out there
can share their expertise.

Should I use 'cd subdir' and 'cd ..' in order to navigate, compile and
link?

or

Perhaps there is a better way?

The reason I ask is because I recall some "virtual directory" (or
similar concept, maybe "virtual path"?) when I had to install complex,
multi-directory software.

Maybe it's time to use such fancy feature?

TIA,

-Ramon

Ramon F Herrera <ramon@conexus.net> writes:

> I need a little assistance to move up the `make' learning curve.
>
> I have been using `make' for ages, but my Makefiles are simple in the
> sense that all the files have always resided in the same directory.
>
> I have a new project, however, which will contain its component files
> (lots of 'em) at 2 or 3 levels, under the same top directory.
>
> Before I start experimenting, perhaps some of the experts out there
> can share their expertise.
>
> Should I use 'cd subdir' and 'cd ..' in order to navigate, compile and
> link?
>
> or
>
> Perhaps there is a better way?
>
> The reason I ask is because I recall some "virtual directory" (or
> similar concept, maybe "virtual path"?) when I had to install complex,
> multi-directory software.
>
> Maybe it's time to use such fancy feature?

Sometimes it is  useful to use cd in the commands.   The trick here is
that each  command line is executed  separately, so you have  do cd on
each line:

    target:
        cd $(SUBDIR) ; do-something
        cd $(SUBDIR) ; do-something-else

or to put everything on a single line:

    target:
        cd $(SUBDIR) ;\
          do-something ;\
          do-something-else


However, having subprojects in subdirectories should not be a reason
to use cd.  Not really.  Read this: 

    Recursive Make Considered Harmful
    http://aegis.sourceforge.net/auug97.pdf


However, if you insist on recursive make, you can use them with the -C
option, so you don't even have to use cd explicitely:

    target:
        $(MAKE) $(MFLAGS) -C $(SUBDIR)  subtarget

-- 
__Pascal Bourguignon__

On Sep 2, 4:57=A0am, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> Ramon F Herrera <ra...@conexus.net> writes:
>
>
>
> > I need a little assistance to move up the `make' learning curve.
>
> > I have been using `make' for ages, but my Makefiles are simple in the
> > sense that all the files have always resided in the same directory.
>
> > I have a new project, however, which will contain its component files
> > (lots of 'em) at 2 or 3 levels, under the same top directory.
>
> > Before I start experimenting, perhaps some of the experts out there
> > can share their expertise.
>
> > Should I use 'cd subdir' and 'cd ..' in order to navigate, compile and
> > link?
>
> > or
>
> > Perhaps there is a better way?
>
> > The reason I ask is because I recall some "virtual directory" (or
> > similar concept, maybe "virtual path"?) when I had to install complex,
> > multi-directory software.
>
> > Maybe it's time to use such fancy feature?
>
> Sometimes it is =A0useful to use cd in the commands. =A0 The trick here i=
s
> that each =A0command line is executed =A0separately, so you have =A0do cd=
 on
> each line:
>
> =A0 =A0 target:
> =A0 =A0 =A0 =A0 cd $(SUBDIR) ; do-something
> =A0 =A0 =A0 =A0 cd $(SUBDIR) ; do-something-else
>
> or to put everything on a single line:
>
> =A0 =A0 target:
> =A0 =A0 =A0 =A0 cd $(SUBDIR) ;\
> =A0 =A0 =A0 =A0 =A0 do-something ;\
> =A0 =A0 =A0 =A0 =A0 do-something-else
>
> However, having subprojects in subdirectories should not be a reason
> to use cd. =A0Not really. =A0Read this:
>
> =A0 =A0 Recursive Make Considered Harmful
> =A0 =A0http://aegis.sourceforge.net/auug97.pdf
>
> However, if you insist on recursive make, you can use them with the -C
> option, so you don't even have to use cd explicitely:
>
> =A0 =A0 target:
> =A0 =A0 =A0 =A0 $(MAKE) $(MFLAGS) -C $(SUBDIR) =A0subtarget
>
> --
> __Pascal Bourguignon__


Merci beaucoup, Pascal!

I wonder is there are some automated tool(s) to check Makefiles...

-Ramon

Ramon F Herrera <ramon@conexus.net> writes:
> I wonder is there are some automated tool(s) to check Makefiles...

I know none.  You can use   make -n   to process the makefile without
actually executing the commands. (See also the -d, -q and -p options).

If you had some specific check in mind, it should not be too difficult
to patch the sources of gnu make to add these checks.

One difficulty would be to decide what kind of makefile you want to
handle.  There's an original unix make with its various versions,
there is GNU make, and then there are a lot of variants, imake, cmake,
nmake, that use a similar makefile format, plus an even bigger number
of variants such as ant, asdf, scons, etc implementing basically the
same principle but with additionnal features and very different file
formats.  

-- 
__Pascal Bourguignon__

On Sep 1, 8:37=A0pm, Ramon F Herrera <ra...@conexus.net> wrote:
> I need a little assistance to move up the `make' learning curve.
>
> I have been using `make' for ages, but my Makefiles are simple in the
> sense that all the files have always resided in the same directory.
>
> I have a new project, however, which will contain its component files
> (lots of 'em) at 2 or 3 levels, under the same top directory.
>
> Before I start experimenting, perhaps some of the experts out there
> can share their expertise.
>
> Should I use 'cd subdir' and 'cd ..' in order to navigate, compile and
> link?
>
> or
>
> Perhaps there is a better way?
>
> The reason I ask is because I recall some "virtual directory" (or
> similar concept, maybe "virtual path"?) when I had to install complex,
> multi-directory software.
>
> Maybe it's time to use such fancy feature?
>
> TIA,
>
> -Ramon


Here's a related article, Ramon

- Your Self.

http://www.cmcrossroads.com/content/view/11088/268/

"Pascal J. Bourguignon" <pjb@informatimago.com> wrote in message 
news:7c8wgxpvut.fsf@pbourguignon.anevia.com...
> Ramon F Herrera <ramon@conexus.net> writes:
>
>> I need a little assistance to move up the `make' learning curve.
>>
>> I have been using `make' for ages, but my Makefiles are simple in the
>> sense that all the files have always resided in the same directory.
>>
>> I have a new project, however, which will contain its component files
>> (lots of 'em) at 2 or 3 levels, under the same top directory.
>>
>> Before I start experimenting, perhaps some of the experts out there
>> can share their expertise.
>>
>> Should I use 'cd subdir' and 'cd ..' in order to navigate, compile and
>> link?
>>
>> or
>>
>> Perhaps there is a better way?
>>
>> The reason I ask is because I recall some "virtual directory" (or
>> similar concept, maybe "virtual path"?) when I had to install complex,
>> multi-directory software.
>>
>> Maybe it's time to use such fancy feature?
>
> Sometimes it is  useful to use cd in the commands.   The trick here is
> that each  command line is executed  separately, so you have  do cd on
> each line:
>
>    target:
>        cd $(SUBDIR) ; do-something
>        cd $(SUBDIR) ; do-something-else
>
> or to put everything on a single line:
>
>    target:
>        cd $(SUBDIR) ;\
>          do-something ;\
>          do-something-else
>
>
> However, having subprojects in subdirectories should not be a reason
> to use cd.  Not really.  Read this:
>
>    Recursive Make Considered Harmful
>    http://aegis.sourceforge.net/auug97.pdf
>
>
> However, if you insist on recursive make, you can use them with the -C
> option, so you don't even have to use cd explicitely:
>
>    target:
>        $(MAKE) $(MFLAGS) -C $(SUBDIR)  subtarget
>

paper: interesting...

yep, I use recursive make, and yes, if doing the whole project, the thing is 
slow...
(I tried using the 'AMD CodeAnalyst' tool on it, and apparently most of the 
time is going into the OS...).


so, make takes a fairly long time to do its thing, but it is funny in that 
MSVC itself is actually fairly fast (I am using GNU Make+MSVC here...).

actually, I mentioned it elsewhere (other groups):
but, it seems to me there is a speed difference between GCC and MSVC, where 
GCC tends to take about several seconds per source file (for this particular 
project), but MSVC does several files per second (granted, this is when 
passing in all of the files on the command line at once, where MSVC seems to 
batch compile them somehow...).

granted, compile times are partly the fault of my include-file structure 
(essentially, it forms a big tree structure, and often including a header 
will pull in several MB of stuff, as I have noted with my own C 
compiler...).

for my custom compiler, I added support for a vaguely similar sort of 
"batch" mode, which "should" help with making my compiler faster at least (I 
say "should" as it is not really tested). I took a simple internal approach 
of simply generating a single (internal) module which "#include"s all of the 
modules given to it (and then compiles this module).

what I am expecting here is that the usual "#ifndef/#define" guards for the 
headers will eliminate multiple inclusion, making the headers only be 
included once per batch.

the main cost being that of potential ANSI violation (and in some rare 
cases, code may not like being built this way...).

(note: I suspect MSVC works differently, mostly as it will produce an object 
file for each source file, but it seems like other things merge together in 
the final DLL, whereas in my case, simply lumping all of the modules would 
only likely produce a single object file if one were produced, ...).


but, yeah, slowness of make is the main issue...

in my case, I tend to use a multi-pass make process:
'includes', which basically makes sure any headers/... are up to date (many 
of my headers are tool-generated, this pass may also build some of the 
needed tools);
'libs', which attempts to build libraries (DLL's, ...);
'apps', which goes and rebuilds any EXE's;
....

this process also uses some amount of file copying (mostly, each level 
gathers up all of the relevant files built by sub-levels, such as the 
contents of 'include' directories, DLL's, LIB's, EXE's, ...).


as for build-management:
internally, my compiler (which is mostly a dynamic/JIT style C compiler) 
mostly uses "build scripts", which are much simpler than Makefiles (the 
compiler is smart enough to figure how to build stuff, it only needs to be 
told what to build and what the source files are, ...), and primarily does 
its own dependency tracking via an internal database-like structure (it 
forms a DAG on top of the DB entries). dependency info is typically mined 
from the source files themselves, and ammusingly the DB tracks headers and 
other things as well (an earlier version included a precompiled header 
mechanism, but this was dropped with a rewrite, partly because it was 
awkward, unstable, and really didn't help that much...).

actually, I may also note that conventional Makefiles / Make-like build 
management, does not make as much sense when there is no shell, and so the 
compiler is an "entity of some sort", rather than some particular command to 
be invoked.

so, the "command" is instead "source <files*>" or "multi <modname> <files*>" 
(where 'source' builds files individually, and 'multi' merges them all into 
a single module...).

I had at times considered extending this to supporting static builds (and 
static compilers), but had not done so (since, hell, the Makefiles work...).

"BGB / cr88192" <cr88192@hotmail.com> writes:
> so, make takes a fairly long time to do its thing, but it is funny in that 
> MSVC itself is actually fairly fast (I am using GNU Make+MSVC here...).
>
> actually, I mentioned it elsewhere (other groups):
> but, it seems to me there is a speed difference between GCC and MSVC, where 
> GCC tends to take about several seconds per source file (for this particular 
> project), but MSVC does several files per second (granted, this is when 
> passing in all of the files on the command line at once, where MSVC seems to 
> batch compile them somehow...).
>
> granted, compile times are partly the fault of my include-file structure 
> (essentially, it forms a big tree structure, and often including a header 
> will pull in several MB of stuff, as I have noted with my own C 
> compiler...).
>
> for my custom compiler, I added support for a vaguely similar sort of 
> "batch" mode, which "should" help with making my compiler faster at least (I 
> say "should" as it is not really tested). I took a simple internal approach 
> of simply generating a single (internal) module which "#include"s all of the 
> modules given to it (and then compiles this module).


Perhaps MSVC use precompiled headers automatically. You would have to
precompile the headers explicitely.

Have a look at http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html

> for my custom compiler, I added support for a vaguely similar sort of 
> "batch" mode, which "should" help with making my compiler faster at least (I 
> say "should" as it is not really tested). I took a simple internal approach 
> of simply generating a single (internal) module which "#include"s all of the 
> modules given to it (and then compiles this module).

You can also give several sources to one gcc command:

    gcc -c *.c



-- 
__Pascal Bourguignon__

"Pascal J. Bourguignon" <pjb@informatimago.com> wrote in message 
news:87vdjxp9f6.fsf@galatea.local...
> "BGB / cr88192" <cr88192@hotmail.com> writes:
>> so, make takes a fairly long time to do its thing, but it is funny in 
>> that
>> MSVC itself is actually fairly fast (I am using GNU Make+MSVC here...).
>>
>> actually, I mentioned it elsewhere (other groups):
>> but, it seems to me there is a speed difference between GCC and MSVC, 
>> where
>> GCC tends to take about several seconds per source file (for this 
>> particular
>> project), but MSVC does several files per second (granted, this is when
>> passing in all of the files on the command line at once, where MSVC seems 
>> to
>> batch compile them somehow...).
>>
>> granted, compile times are partly the fault of my include-file structure
>> (essentially, it forms a big tree structure, and often including a header
>> will pull in several MB of stuff, as I have noted with my own C
>> compiler...).
>>
>> for my custom compiler, I added support for a vaguely similar sort of
>> "batch" mode, which "should" help with making my compiler faster at least 
>> (I
>> say "should" as it is not really tested). I took a simple internal 
>> approach
>> of simply generating a single (internal) module which "#include"s all of 
>> the
>> modules given to it (and then compiles this module).
>
>
> Perhaps MSVC use precompiled headers automatically. You would have to
> precompile the headers explicitely.
>
> Have a look at http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html
>

yeah, I suspect MSVC may do something like this...
like, when compiling a DLL, the first time around it precompiles the 
headers, and for each additional source-file reuses the same precompiled 
headers.

it might also have something to do with my common practice of including a 
single massive header per source file, typically the header associated with 
said library, which itself declares everything generally allowed to be 
used/visible within the library (exceptions exist, but this is the common 
rule).

it is possible MSVC may be able to automatically optimize this case (I am 
aware I am not manually producing any precompiled headers, so I think it may 
automatically build them internally after parsing the first module).

similarly, I have not seen any evidence of external precompiled headers 
having been produced by MSVC (probably it is just done in the course of 
compiling a group of source files into a DLL?...).

note, I am fairly sure the issue is not with system headers, as I have 
before observed (from my own compiler's debugging output) that the vast 
majority of the contents are from my own libraries' headers...


however, I don't see much mention of this feature anywhere, so I don't 
know...

(current version: Platform SDK v6.1 x64, cl version '15.00.21022.08').


as for GCC, I know about precompiled headers.
I have not typically used them though, but I guess it is an option.

having to do anything manually is a detractor though (I am inferring one 
would have to manually set up the Makefile to build the header and keep it 
up to date?...).


in the original frontend for my compiler, its PCH mechanism had 
automatically built said headers, and also automatically managaged their 
dependencies (the dependency DB was used, and in this case it was built 
around partially scanning headers/... to determine what depended on what).

later though, I rewrote the frontend, but did not retain PCH support.


>> for my custom compiler, I added support for a vaguely similar sort of
>> "batch" mode, which "should" help with making my compiler faster at least 
>> (I
>> say "should" as it is not really tested). I took a simple internal 
>> approach
>> of simply generating a single (internal) module which "#include"s all of 
>> the
>> modules given to it (and then compiles this module).
>
> You can also give several sources to one gcc command:
>
>    gcc -c *.c
>

my custom compiler is not GCC, nor is it derived from any GCC sources...


so, when given multiple files in this way, does GCC manage to additionally 
optimize the code or otherwise optimize build times?...


mostly, it is used for something GCC does not do: JIT compilation.

and currently on a platform GCC does not currently support well: Win64 / 
x64.


I am actually using MSVC in the first place because GCC's Win64 support was 
wanting:
AKA, it was teh horridly buggy (generating code with not so minor bugs in 
the produced output, ...). I jumped to MSVC mostly as it could produce code 
which actually worked.

however, I have noticed a few detractors with MSVC as well, such as its code 
generally lacking in optimization (the "optimization" in MSVC, on x64 at 
least, does not win much praise, as even with optimizations turned on, the 
produced code is still not very good...), as well as notable the lack of C99 
features (I am left tempted to just write my own complex number support to 
compensate for MSVC's lack, and as well falling back to my use of 
quaternions for complex support is overkill).


the main halting point is mostly just what name prefix to use exactly, since 
the 'c' prefix is already used by C99's complex support (and I use 'v2', 
'v3', 'v4' and 'q' for my vector and quat support, note that these are 
currently internally based around MSVC SIMD intrinsics, but several 
different implementations exist, including raw structs, and my compilers' 
SIMD extensions).

'c2' is just tacky, 'fc', 'cf' are not well liked (too likely to clash, as 
well as 'd').

unless my support was a partial "simulation"+"wrapper" of C99's support, and 
would essentially "move out of the way" if C99 were detected (allowing me to 
safely use names like 'csqrt', ...). in this case, code could be written the 
same, and the interface would just use C99's complexes if available (and, 
otherwise, provide an implementation based around SIMD intrinsics).

or such...


>
>
> -- 
> __Pascal Bourguignon__