«

James Harris wrote:
>
> Sorry - I tried to keep the description short. Let me go the other way
> and illustrate by using something specific in the form of the
> directory tree you suggested.
>
> Say you wanted to include a header from another directory would you
> write something along the lines or
>
> #include "../../src/utils1/header.h"
>
> or would it be better to write
>
> #include "header.h"
>
> and to add a compile switch along the lines of
>
> --header-source ../../src/utils1
>
> In either case how is it best to specify the referred-to directories?

It's easier to simply write

#include <utils1/header.h>

and have -I <path to src> as one of your compile options.

> Is the idea of relative subdirectories good or should they be absolute
> or should they be relative to a site-chosen base directory?

I prefer the latter.

> Is there a
> better way to specify where the desired header should be looked for
> bearing in mind that there may be multiple generations of a given
> utility and by default the most recent one is wanted?

If you must (why would you?) do that use your source control tool to
manage the branches.

--
Ian Collins

On Tuesday 05 March 2013 15:06, in comp.lang.c, ian- wrote:

> James Harris wrote:
>>
>> Sorry - I tried to keep the description short. Let me go the other way
>> and illustrate by using something specific in the form of the
>> directory tree you suggested.
>>
>> Say you wanted to include a header from another directory would you
>> write something along the lines or
>>
>> #include "../../src/utils1/header.h"
>>
>> or would it be better to write
>>
>> #include "header.h"
>>
>> and to add a compile switch along the lines of
>>
>> --header-source ../../src/utils1
>>
>> In either case how is it best to specify the referred-to directories?
>
> It's easier to simply write
>
> #include <utils1/header.h>
>
> and have -I <path to src> as one of your compile options.

which, with GCC, can be dangerous.

Consider, say you have a source-supplied header called
time.h
in your source directory.

When you
#include <time.h>
in your source, you'll get the source-supplied time.h header from your
source directory rather than the system-supplied time.h header from the
standard include directories.

This happens because GCC searches the directories named by the -I
option /before/ it searches the standard system include directories.
(See the GCC instructions on -I for details).

And, yes, I've seen this happen in at least one source package, where the
authors figured that it was simpler to -I their include library (which
included some non-standard headers named with the same names as standard
headers) than it was to
#include "./path/to/application/include/files/header.h"


--
Lew Pitcher
"In Skills, We Trust"

Lew Pitcher wrote:
> On Tuesday 05 March 2013 15:06, in comp.lang.c, ian- wrote:
>
>> James Harris wrote:
>>>
>>> Sorry - I tried to keep the description short. Let me go the other way
>>> and illustrate by using something specific in the form of the
>>> directory tree you suggested.
>>>
>>> Say you wanted to include a header from another directory would you
>>> write something along the lines or
>>>
>>> #include "../../src/utils1/header.h"
>>>
>>> or would it be better to write
>>>
>>> #include "header.h"
>>>
>>> and to add a compile switch along the lines of
>>>
>>> --header-source ../../src/utils1
>>>
>>> In either case how is it best to specify the referred-to directories?
>>
>> It's easier to simply write
>>
>> #include <utils1/header.h>
>>
>> and have -I <path to src> as one of your compile options.
>
> which, with GCC, can be dangerous.

Anything can be dangerous with any compiler if you break simple common
sense rules.

> Consider, say you have a source-supplied header called
> time.h
> in your source directory.
>
> When you
> #include <time.h>

Which isn't what I wrote.

I never have headers in the top level directory, so the includes are
always of the form <module/header> which is safe. Unless you happen to
shadow the system's header tree, but you'll soon fall over in that case.

> in your source, you'll get the source-supplied time.h header from your
> source directory rather than the system-supplied time.h header from the
> standard include directories.

Which would get fixed either when the code was reviewed, or the first
time it was built.

> This happens because GCC searches the directories named by the -I
> option /before/ it searches the standard system include directories.
> (See the GCC instructions on -I for details).

I've yet to find a compiler that doesn't.

> And, yes, I've seen this happen in at least one source package, where the
> authors figured that it was simpler to -I their include library (which
> included some non-standard headers named with the same names as standard
> headers) than it was to
> #include "./path/to/application/include/files/header.h"

...if you break simple common sense rules.

--
Ian Collins

On Mar 5, 9:01*pm, Lew Pitcher <lpitc...@teksavvy.com> wrote:

....

> When you
> * #include <time.h>
> in your source, you'll get the source-supplied time.h header from your
> source directory rather than the system-supplied time.h header from the
> standard include directories.
>
> This happens because GCC searches the directories named by the -I
> option /before/ it searches the standard system include directories.
> (See the GCC instructions on -I for details).

I would have thought a compiler would/should allow a separate set of
directories for quoted includes as opposed to angle bracket includes
because the programmer's intent is different. In fact GCC seems to
support this differentiation with the -I- option and the -iquote
option.

James

On Mon, 04 Mar 2013 13:54:33 -0800, Paul N wrote:

> On Mar 4, 4:55Â*pm, Shao Miller <sha0.mil...@gmail.com> wrote:
>
>> A top-level Makefile can invoke a Makefile in each subdir of src/
>
> Isn't that what is warned about in
> http://miller.emu.id.au/pmiller/books/rmch/ "Recursive Make Considered
> Harmful" ?

Yes, but s/invoke a Makefile in/include a Makefile fragment from/ in the
quote from Shao Miller and the objections from that article are also
covered.

Bart v Ingen Schenau

On Tue, 05 Mar 2013 03:10:17 -0800, James Harris wrote:

> On Mar 4, 11:55Â*pm, Shao Miller <sha0.mil...@gmail.com> wrote:
>
> ...
>
>> > ... I was more interested in how C programmers organise their source
>> > code directories etc so that one module can refer to modules in other
>> > directories.
>>
>> I think it's fairly subjective. Â*There haven't been too many
>> respondents to the thread, so it might even be too far from C to
>> interest others.
>
> It did seem odd at first. I thought there would have been a number of
> suggestions over how best to organise C source code for multiple
> projects. After all, we tend to build up loads of code after programming
> for a few years, some of it utility code that is used in different
> projects. The code has to be stored somewhere! Possibly there were few
> other replies because people agreed with or had little to add to the
> first suggestion made. Or perhaps there are no common approaches that C
> programmers use. Or maybe folks don't address the specific things I was
> asking about. At any rate, I appreciate the help with this from you and
> Malcolm. It has given me some ideas for ways to get started.

Another possibility is that it is actually quite rare to have the code
for multiple projects in a single tree.
Most often, a single source-tree only contains the code for a single
project, and a project uses only a single version of each module (which
can change over time as new versions become available, but at each point
in time there is only one version in use by a particular project).

As for where code gets stored, that is in a repository of a version
control system (VCS), like Subversion or Git. To some extent the
repository layout must mirror the directory structure of the sources on
disk, but it is certainly not a one-to-one correspondence.

>
> James

Bart v Ingen Schenau

On Sat, 2013-03-02, James Harris wrote:
....
> At some point - might as well be now - I think I will need to use some
> source code management application: GIT, Bazaar, Subversion or
> similar.

It should be now. Good free tools have existed for over thirty years;
not using them is just a way to create more problems for yourself.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

On Sat, 2013-03-02, James Harris wrote:
> Up to now I have usually written C modules as stand alone programs and
> stored them in separate directories. This has been OK but is
> inflexible, making interaction between them and having multiple
> generations of a given piece of code awkward. Have you guys any
> suggestions on how to organise C source code for use when developing
> small to medium size projects?
>
> This may be a generic query and maybe you use a certain tried and
> tested scheme for every C program you write but if it helps to explain
> the context it is as follows.
>
> I would like to adopt a scheme that I can use for all C code from now
> on. The model I have in mind is to have some apps (by which I mean
> things such as user-facing programs) and some utilities.
....

> Sorry that's a long list. Hopefully it is a fairly standard set of
> requirements!

I remember wondering about all this (natural, since books and
courses rarely cover it).

But I think you're thinking too hard, and trying to find a general
solution to something which is much easier to solve on a case-by-case
basis. You're also inventing terminology (apps, utilities) which I
don't understand.

I have a humble set of hobby projects. They're in version control
(CVS, Git) so there's a structure enforced there already: anything I
want to say "this is version 3.14 of FooBar" about has to be separated
from "Barney 2.18".

Almost all of them are just a flat directory, plus a test/
subdirectory. I have considered creating utility libraries to reuse,
but in the end I decided against it[1]. If there's something I really
need in two projects, I copy it, but remember that there are now two
copies. If the need continues, I can always split it out later. This
hasn't happened so far, and it hasn't been a major problem[2].

/Jorgen

[1] Started to design a socket library, but realized that without an
application, it was just masturbation, and would end up with me
designing a lot of stuff with no practical purpose.

[2] I should add here that I mostly use C++, so there are fewer basic
building blocks missing which I have to provide myself.

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

On Mar 6, 4:05*pm, Bart van Ingen Schenau
<b...@ingen.ddns.info.invalid> wrote:
> On Tue, 05 Mar 2013 03:10:17 -0800, James Harris wrote:
> > On Mar 4, 11:55*pm, Shao Miller <sha0.mil...@gmail.com> wrote:
>
> > ...
>
> >> > ... I was more interested in how C programmers organise their source
> >> > code directories etc so that one module can refer to modules in other
> >> > directories.
>
> >> I think it's fairly subjective. *There haven't been too many
> >> respondents to the thread, so it might even be too far from C to
> >> interest others.
>
> > It did seem odd at first. I thought there would have been a number of
> > suggestions over how best to organise C source code for multiple
> > projects. After all, we tend to build up loads of code after programming
> > for a few years, some of it utility code that is used in different
> > projects. The code has to be stored somewhere! Possibly there were few
> > other replies because people agreed with or had little to add to the
> > first suggestion made. Or perhaps there are no common approaches that C
> > programmers use. Or maybe folks don't address the specific things I was
> > asking about. At any rate, I appreciate the help with this from you and
> > Malcolm. It has given me some ideas for ways to get started.
>
> Another possibility is that it is actually quite rare to have the code
> for multiple projects in a single tree.
> Most often, a single source-tree only contains the code for a single
> project, and a project uses only a single version of each module (which
> can change over time as new versions become available, but at each point
> in time there is only one version in use by a particular project).

except we usually end up supporting multiple versions

> As for where code gets stored, that is in a repository of a version
> control system (VCS), like Subversion or Git. To some extent the
> repository layout must mirror the directory structure of the sources on
> disk, but it is certainly not a one-to-one correspondence.

On Mar 8, 9:22*pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
> On Sat, 2013-03-02, James Harris wrote:
> > Up to now I have usually written C modules as stand alone programs and
> > stored them in separate directories. This has been OK but is
> > inflexible, making interaction between them and having multiple
> > generations of a given piece of code awkward. Have you guys any
> > suggestions on how to organise C source code for use when developing
> > small to medium size projects?
>
> > This may be a generic query and maybe you use a certain tried and
> > tested scheme for every C program you write but if it helps to explain
> > the context it is as follows.
>
> > I would like to adopt a scheme that I can use for all C code from now
> > on. The model I have in mind is to have some apps (by which I mean
> > things such as user-facing programs) and some utilities.
>
> ...
>
> > Sorry that's a long list. Hopefully it is a fairly standard set of
> > requirements!
>
> I remember wondering about all this (natural, since books and
> courses rarely cover it).
>
> But I think you're thinking too hard, and trying to find a general
> solution to something which is much easier to solve on a case-by-case
> basis. *You're also inventing terminology (apps, utilities) which I
> don't understand.
>
> I have a humble set of hobby projects. *They're in version control
> (CVS, Git) so there's a structure enforced there already: anything I
> want to say "this is version 3.14 of FooBar" about has to be separated
> from "Barney 2.18".
>
> Almost all of them are just a flat directory, plus a test/
> subdirectory. I have considered creating utility libraries to reuse,
> but in the end I decided against it[1]. *If there's something I really
> need in two projects, I copy it, but remember that there are now two
> copies. *If the need continues, I can always split it out later. This
> hasn't happened so far, and it hasn't been a major problem[2].
>
> /Jorgen
>
> [1] Started to design a socket library, but realized that without an
> * * application, it was just masturbation, and would end up with me
> * * designing a lot of stuff with no practical purpose.
>
> [2] I should add here that I mostly use C++, so there are fewer basic
> * * building blocks missing which I have to provide myself.

well maybe fewer but still a lot of them! I have shared libraries for
such things as logging, printing, reading configuration files. If
projects do similar things they share similar facilities (graphics or
maths)