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

Groups > comp.lang.misc > #3851 > unrolled thread

Compiling and linking code from different places in the file system

Back to article view | Back to comp.lang.misc

Contents

  Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-01 14:40 +0000
    Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-01 14:55 +0000
      Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-02 21:05 +0000
        Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-03 01:18 +0000
          Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-09 01:03 +0000
        Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-06 06:40 -0500
          Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-06 21:10 +0000
            Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-07 06:58 -0500
              Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-09 01:23 +0000
                Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-09 02:28 -0500
                  Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-09 02:44 -0500
                  Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-09 23:26 +0000
                    Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-11 07:44 -0400
                      Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-12 21:59 +0000
                        Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-14 01:45 -0400
                          Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-14 10:59 +0000
        Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-06 06:40 -0500
          Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-06 21:20 +0000
            Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-07 06:58 -0500
              Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-09 10:30 +0000
    Re: Compiling and linking code from different places in the file system "James R. Kuyper" <jameskuyper@verizon.net> - 2018-03-01 11:11 -0500
      Re: Compiling and linking code from different places in the file system "James R. Kuyper" <jameskuyper@verizon.net> - 2018-03-01 13:51 -0500
      Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-03 09:48 +0000
    Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-03 12:25 +0000
      Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-03 15:32 +0000
        Re: Compiling and linking code from different places in the file system Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-04 07:52 +0000
        Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-04 08:43 +0000
          Re: Compiling and linking code from different places in the file system Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-05 07:58 +0000
            Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-06 21:37 +0000
              Re: Compiling and linking code from different places in the file system Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-07 21:02 +0000
          Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-05 15:29 +0000
            Re: Compiling and linking code from different places in the file system rugxulo@gmail.com - 2018-03-06 18:23 -0800
            Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-07 04:54 +0000
              Re: Compiling and linking code from different places in the file system Robert Wessel <robertwessel2@yahoo.com> - 2018-03-07 00:33 -0600
                Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-07 09:55 +0000
                Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-07 17:29 +0000
    Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-06 06:39 -0500
      Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-07 10:44 +0000
        Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-07 06:57 -0500
          Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-09 10:28 +0000
            Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-11 07:44 -0400
              Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-12 22:44 +0000
                Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-14 01:47 -0400
                  Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-14 10:23 +0000
                    Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-14 11:30 +0100
                      Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-14 11:30 +0000
                        Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-14 13:30 +0100
                          Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-14 14:32 +0000
                            Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-14 16:01 +0100
                              Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-14 19:28 +0000
                                Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-15 08:59 +0100
                                  Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-15 19:21 +0000
                                    Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-16 08:08 +0100
                                      Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-16 11:12 +0000
                                        Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-16 16:45 +0100
                                        Re: Compiling and linking code from different places in the file system Andy Walker <anw@cuboid.co.uk> - 2018-03-16 16:09 +0000
                                          Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-16 18:42 +0100
                                          Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-17 18:32 +0000
                                            Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-17 21:37 +0100
                                              Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-17 21:00 +0000
                                                Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-18 11:39 +0100
                                                  Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-18 12:29 +0000
                                            Re: Compiling and linking code from different places in the file system Andy Walker <anw@cuboid.co.uk> - 2018-03-19 13:38 +0000
                                              Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-20 05:40 +0000
                                                Re: Compiling and linking code from different places in the file system Andy Walker <anw@cuboid.co.uk> - 2018-03-20 11:05 +0000
                                                  Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-21 06:03 +0000
                                                    Re: Compiling and linking code from different places in the file system Andy Walker <anw@cuboid.co.uk> - 2018-03-21 18:51 +0000
                                                      Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-21 19:55 +0000
                                                        Re: Compiling and linking code from different places in the file system Andy Walker <anw@cuboid.co.uk> - 2018-03-23 18:03 +0000
                                                          Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-23 20:13 +0000
                                                            Re: Compiling and linking code from different places in the file system Andy Walker <anw@cuboid.co.uk> - 2018-03-24 01:30 +0000
                                                              Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-24 16:48 +0000
                                                                Re: Compiling and linking code from different places in the file system Andy Walker <anw@cuboid.co.uk> - 2018-03-26 19:42 +0100
                                                                  Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-26 22:35 +0100
                                                            Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-24 12:01 +0100
                                                      Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-23 20:58 +0100
                                                Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-23 20:49 +0100
                                              Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-20 18:37 +0000
                                                Re: Compiling and linking code from different places in the file system Andy Walker <anw@cuboid.co.uk> - 2018-03-21 19:33 +0000
                                                  Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-21 20:35 +0000
                                                    Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-23 21:10 +0100
                                                      Re: Compiling and linking code from different places in the file system Marco van de Voort <marcov@toad.stack.nl> - 2018-04-19 06:47 +0000
                                                    Re: Compiling and linking code from different places in the file system Andy Walker <anw@cuboid.co.uk> - 2018-03-27 00:58 +0100
                                                      Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-30 19:55 +0100
                                                  Re: Compiling and linking code from different places in the file system Marco van de Voort <marcov@toad.stack.nl> - 2018-04-19 06:49 +0000
                                                Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-23 21:04 +0100
                                                  Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-23 21:54 +0000
                                                    Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-24 11:22 +0100
                                                      Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-24 12:12 +0000
                                                        Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-24 13:15 +0100
                                                        Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-24 13:36 +0100
                                                          Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-24 14:52 +0000
                                                  Re: Compiling and linking code from different places in the file system Marco van de Voort <marcov@toad.stack.nl> - 2018-04-19 11:06 +0000
                        Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-14 16:52 +0100
                          Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-14 19:38 +0000
                            Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-15 09:00 +0100
                              Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-15 12:54 +0000
                  Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-14 11:18 +0000
                    Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-14 13:52 +0100
                    Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-15 06:29 -0400
                      Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-15 20:37 +0000
                        Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-17 11:51 -0400
                          Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-20 06:31 +0000
                            Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-20 17:14 -0400
                              Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-21 07:10 +0000
                                Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-24 01:38 -0400
                                  Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-24 16:10 +0000
                                    Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-24 20:05 -0400
                                      Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-25 16:55 +0100
    Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-14 13:39 +0100

Page 1 of 6  [1] 2 3 4 5 6  Next page →

#3851 — Compiling and linking code from different places in the file system

It is normal in C programming for any source file which exports 
identifiers to have an associated header file which /describes/ the 
identifiers the source exports. For example, in a folder called PP then 
the two files might be named

   PP/SS.c  (the source)
   PP/SS.h  (the header describing SS.c's exports)

When another source file, say UU.c, imports an identifier that SS.c 
exports it would naturally contain a statement which brings in the 
header at compile time.

   UU.c
     #include "SS.h"

Because C has no concept of a hierarchical namespace here, i.e. the 
source file cannot say "include PP/SS.h" or "include SS.h from folder 
PP", the compiler has to be told about folder PP so it looks in it for 
the header. And that leads to my first query. (Yes, there is one!) If a 
given source file SS.c includes many headers, and the headers could be 
scattered to the four winds - i.e. distributed around the file system - 
in a really big project what's a good way of specifying where the 
compiler should look for included headers?

One options is, of course, to use a separate compile command for each 
source file. But that could end up being a bit cumbersome. And it would 
- at least ostensibly - prevent automatic generation of the compile 
commands - which is what I am essentially intending to do.

Another option is, rather than associate a search path with each 
individual source file, to say that a certain path should be used for 
all .c files in a given folder. But then that might require the source 
code be grouped in a certain way that doesn't suit the project at hand. 
(Maybe.)

At the moment I normally take the easy route and keep all the source 
code for a given project in just one one folder or in a few folders. But 
as projects get larger that approach does not scale at all well, and I 
need to improve both how I lay out project code - and especially what I 
do when one project needs to import files from another.

Irrespective of whether the build is being done under Unix or Windows or 
whatever OS, what's a good way to specify the include folders (e.g. on 
Unix those folder names which have to appear after -I on the compiler 
command line) so that its easy enough even in a big project to generate 
the necessary compile commands?



-- 
James Harris

[toc] | [next] | [standalone]

#3852

On 01/03/2018 14:40, James Harris wrote:
> 
> It is normal in C programming for any source file which exports 
> identifiers to have an associated header file which /describes/ the 
> identifiers the source exports. For example, in a folder called PP then 
> the two files might be named
> 
>    PP/SS.c  (the source)
>    PP/SS.h  (the header describing SS.c's exports)
> 
> When another source file, say UU.c, imports an identifier that SS.c 
> exports it would naturally contain a statement which brings in the 
> header at compile time.
> 
>    UU.c
>      #include "SS.h"
> 
> Because C has no concept of a hierarchical namespace here, i.e. the 
> source file cannot say "include PP/SS.h" or "include SS.h from folder 
> PP", the compiler has to be told about folder PP so it looks in it for 
> the header.

C doesn't have module namespaces, but that doesn't stop you using file 
paths for an include file. So you can say:

   #include "PP/SS.h"

Although this will likely be taken to mean "./PP/SS.h". If the 'current 
source file' is already in "/PP", then that might mean "/PP/PP/SS.h".

Which brings up another point, in that the algorithm for working out 
where to look for an include file, given:

  * The set of Include paths specified to the compiler
  * Whether this is a <...> or "..." file specifier
  * The location of the 'current source file' (which can be an existing
    deeply nested include file, and can involve a stack)
  * Whether the specified path is relative or absolute (within the
    #include directive; don't forget the -I options to the compiler
    can also be relative or absolute)

can get complicated. And I believe is 'implementation defined'.

So it can become a bit of a nightmare, as you go on to suggest. (One 
file accidentally gets deleted, but the search algorithm finds another 
of the same name, sufficiently similar to allow the program to be 
compiled - wrongly.)

-- 
bartc

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

#3856

On 01/03/2018 14:55, bartc wrote:
> On 01/03/2018 14:40, James Harris wrote:
>>
>> It is normal in C programming for any source file which exports
>> identifiers to have an associated header file which /describes/ the
>> identifiers the source exports. For example, in a folder called PP then
>> the two files might be named
>>
>>     PP/SS.c  (the source)
>>     PP/SS.h  (the header describing SS.c's exports)
>>
>> When another source file, say UU.c, imports an identifier that SS.c
>> exports it would naturally contain a statement which brings in the
>> header at compile time.
>>
>>     UU.c
>>       #include "SS.h"
>>
>> Because C has no concept of a hierarchical namespace here, i.e. the
>> source file cannot say "include PP/SS.h" or "include SS.h from folder
>> PP", the compiler has to be told about folder PP so it looks in it for
>> the header.
> 
> C doesn't have module namespaces, but that doesn't stop you using file
> paths for an include file. So you can say:
> 
>     #include "PP/SS.h"

Yes, I forgot about that. My query was meant to be about the principle 
rather than C per se.

If one thinks of each folder as a namespace (reasons below), the query 
is about how to tell a compiler which namespaces to search in order to 
find #include targets. They would probably normally be specified on the 
command line with a -I or the like, but an environment variable 
containing the list would do just as well if that's how a certain 
compiler worked. The problem is not how to tell the compiler (strictly, 
the preprocessor) about them but about how to know which namespaces to 
use for any particular invocation of the compiler.

Best I can think of so far is to have a configuration file or files 
which uses wildcards to say which namespaces to use for each source 
file. The wildcards would be there to avoid specifying a list for each 
file individually.

For example, assuming that the namespaces to search have already been 
defined as nss[N] for various N, a configuration file could include the 
following lines.

   folder1/folder1.1/source.c nss[0]
   folder1/folder1.1/* nss[1]
   folder1/* [nss2]
   * nss[3]

That's intended to say that source.c should be compiled with the 
namespaces mentioned in nss[0], that other sources in folder1.1 should 
be compiled with nss[1], and so on.

Does that make sense? Am I missing an easier way?

Another issue is whether there should be one such configuration file per 
'project' or whether it ought to be possible to have configuration files 
in subfolders supplying info about them and folders lower down in the tree.

> 
> Although this will likely be taken to mean "./PP/SS.h". If the 'current
> source file' is already in "/PP", then that might mean "/PP/PP/SS.h".
> 
> Which brings up another point, in that the algorithm for working out
> where to look for an include file, given:
> 
>    * The set of Include paths specified to the compiler
>    * Whether this is a <...> or "..." file specifier
>    * The location of the 'current source file' (which can be an existing
>      deeply nested include file, and can involve a stack)
>    * Whether the specified path is relative or absolute (within the
>      #include directive; don't forget the -I options to the compiler
>      can also be relative or absolute)
> 
> can get complicated. And I believe is 'implementation defined'.
> 
> So it can become a bit of a nightmare, as you go on to suggest. (One
> file accidentally gets deleted, but the search algorithm finds another
> of the same name, sufficiently similar to allow the program to be
> compiled - wrongly.)

On that, I think that to do this properly there may be a need for what 
you might call "namespace algebra"! Specifically, there may be a need 
for two ways to combine namespaces:

1. Names must be unique - i.e. no duplicates in another namespace.
2. Names can be the same but the namespaces are ordered and the first 
namespace which contains the name is the one which is used.

I did look up to see if there was some computer-sciencey set of theories 
about namespace manipulation and didn't find any, but such operations 
are used repeatedly so this can be nothing new.

Maybe allowing those two ways would resolve the issue you mention.


-- 
James Harris

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

#3857

On 02/03/2018 21:05, James Harris wrote:
> On 01/03/2018 14:55, bartc wrote:

> If one thinks of each folder as a namespace (reasons below),

There are similarities between file paths and qualified/part-qualified 
names in a language, but I think it's confusing to mix them up.

  the query
> is about how to tell a compiler which namespaces to search in order to 
> find #include targets. They would probably normally be specified on the 
> command line with a -I or the like, but an environment variable 
> containing the list would do just as well if that's how a certain 
> compiler worked. The problem is not how to tell the compiler (strictly, 
> the preprocessor) about them but about how to know which namespaces to 
> use for any particular invocation of the compiler.

I came across a good example today, an open source C project called 
'micropython'. Building it is complex, but there is no overview in 
English. I can get it to build using MSBUILD (created an exe for 
Windows), but it is an opaque process and I have no idea what is going on.

The base set of .c files are in a path "c:\mpython\py".

A typical file is c:\mpython\py\gc.c, but a casual compiation of gc.c 
won't work, because it uses '#include "py/gc.h"', and it can't find gc.h 
even though it's right next to gc.c in the same directory.

This is exactly the mixup in the example I gave.

To casually build such a one-off source file using gcc, I have to give 
it this set of includes:

-Ic:/mpython/py
-Ic:/mpython
-Ic:/mpython/ports/windows
-Ic:/mpython/ports/windows/build

Because there are various nested includes to locate too. One of them 
contains this:

#ifdef MP_CONFIGFILE
  #include MP_CONFIGFILE
#else
  #include <mpconfigport.h>
#endif

Clearly, some complexity here is due to requiring different sets of 
include files depending on build target. But the way that is solved in 
such C projects is always very elaborate. There are 20 makefiles in the 
project, all full of gobbledygook.

Instead of being properly documented so that people can appreciate the 
issues, understand how they have been solved, have the ability to devise 
their own solutions, or make it possible to debug when things don't 
work, all that know-how is buried away as cryptic syntax inside things 
such as configure scripts, makefiles and VS project files.

Anyway, rant over.

> For example, assuming that the namespaces to search have already been 
> defined as nss[N] for various N, a configuration file could include the 
> following lines.
> 
>    folder1/folder1.1/source.c nss[0]
>    folder1/folder1.1/* nss[1]
>    folder1/* [nss2]
>    * nss[3]
> 
> That's intended to say that source.c should be compiled with the 
> namespaces mentioned in nss[0], that other sources in folder1.1 should 
> be compiled with nss[1], and so on.
> 
> Does that make sense? Am I missing an easier way?

If using C, don't forget it doesn't have namespaces, this is just about 
locating the right .h files (sometimes, the right .c file if included).

In the case of the two files gc.c and gc.h of my example project which 
reside in the same place, then my gc.c would contain:

   #include "gc.h"

and it will be able to find it easily as the first place the compiler 
should look is in the same path as the current source file.

So just keep things simple and sensible as much as possible.

> On that, I think that to do this properly there may be a need for what 
> you might call "namespace algebra"! Specifically, there may be a need 
> for two ways to combine namespaces:
> 
> 1. Names must be unique - i.e. no duplicates in another namespace.

Part of the reason for namespaces is to be able to reuse the same names 
in different contexts - different paths or different namespaces.

It's the top-level name that needs to be unique.

> I did look up to see if there was some computer-sciencey set of theories 
> about namespace manipulation and didn't find any, but such operations 
> are used repeatedly so this can be nothing new.
> 
> Maybe allowing those two ways would resolve the issue you mention.

In my non-C projects, I use an import system. That solves some of the 
issues mentioned, but not all. For a start, no actual file names or file 
paths are specified in source code (Python uses something similar).

I haven't tried a more complex project like the micropython one, but I 
would expect to spend time on the simplest, least painful solution.

(In the C projects I distribute, those tend to be a single .c file with 
no .h files, so such problems don't arise! Because I know things can 
rapidly get fiddly.)

-- 
bartc

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

#3882

On 03/03/2018 01:18, bartc wrote:
> On 02/03/2018 21:05, James Harris wrote:
>> On 01/03/2018 14:55, bartc wrote:
> 
>> If one thinks of each folder as a namespace (reasons below),
> 
> There are similarities between file paths and qualified/part-qualified
> names in a language, but I think it's confusing to mix them up.

AISI if a namespace is a container such that names within it are 
distinct (but can match names used outside the container) then a folder 
is a namespace. That's nothing to do with programming or programming 
languages or how they use the term.

..

 >>
>> On that, I think that to do this properly there may be a need for what
>> you might call "namespace algebra"! Specifically, there may be a need
>> for two ways to combine namespaces:
>>
>> 1. Names must be unique - i.e. no duplicates in another namespace.
> 
> Part of the reason for namespaces is to be able to reuse the same names
> in different contexts - different paths or different namespaces.
> 
> It's the top-level name that needs to be unique.
> 
>> I did look up to see if there was some computer-sciencey set of theories
>> about namespace manipulation and didn't find any, but such operations
>> are used repeatedly so this can be nothing new.
>>
>> Maybe allowing those two ways would resolve the issue you mention.
> 
> In my non-C projects, I use an import system. That solves some of the
> issues mentioned, but not all. For a start, no actual file names or file
> paths are specified in source code (Python uses something similar).
> 
> I haven't tried a more complex project like the micropython one, but I
> would expect to spend time on the simplest, least painful solution.
> 
> (In the C projects I distribute, those tend to be a single .c file with
> no .h files, so such problems don't arise! Because I know things can
> rapidly get fiddly.)
> 

I'm glad I posed the original query. It's been bothering me for weeks 
that I couldn't get a handle on it but as you point out, it can get 
fiddly - even more so when trying to get a program to cope with 
arbitrary choices that programmers might make.


-- 
James Harris

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

#3867

On Fri, 2 Mar 2018 21:05:12 +0000
James Harris <james.harris.1@gmail.com> wrote:

[dropped c.l.c]

> On that, I think that to do this properly there may be a need for
> what you might call "namespace algebra"! Specifically, there may be a
> need for two ways to combine namespaces:
> 
> 1. Names must be unique - i.e. no duplicates in another namespace.
> 2. Names can be the same but the namespaces are ordered and the first 
> namespace which contains the name is the one which is used.
> 

Why?

If each name is referenced not by name, but by a unique address, then
you could have duplicate names, without collision of the address.  Yes?


Rod Pemberton
-- 
feeback loop:  Russian aggression -> World complains -> Russian
paranioa -> Russian threats -> repeat

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

#3869

On 06/03/2018 11:40, Rod Pemberton wrote:
> On Fri, 2 Mar 2018 21:05:12 +0000
> James Harris <james.harris.1@gmail.com> wrote:
> 
> [dropped c.l.c]
> 
>> On that, I think that to do this properly there may be a need for
>> what you might call "namespace algebra"! Specifically, there may be a
>> need for two ways to combine namespaces:
>>
>> 1. Names must be unique - i.e. no duplicates in another namespace.
>> 2. Names can be the same but the namespaces are ordered and the first
>> namespace which contains the name is the one which is used.
>>
> 
> Why?
> 
> If each name is referenced not by name, but by a unique address, then
> you could have duplicate names, without collision of the address.  Yes?

I'm not sure what you mean. There is no address here. This is all about 
names. I was suggesting that there are two ways to combine namespaces, 
as above.


-- 
James Harris

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

#3879

On Tue, 6 Mar 2018 21:10:37 +0000
James Harris <james.harris.1@gmail.com> wrote:

> On 06/03/2018 11:40, Rod Pemberton wrote:
> > On Fri, 2 Mar 2018 21:05:12 +0000
> > James Harris <james.harris.1@gmail.com> wrote:
> > 
> > [dropped c.l.c]

> >> On that, I think that to do this properly there may be a need for
> >> what you might call "namespace algebra"! Specifically, there may
> >> be a need for two ways to combine namespaces:
> >>
> >> 1. Names must be unique - i.e. no duplicates in another namespace.
> >> 2. Names can be the same but the namespaces are ordered and the
> >> first namespace which contains the name is the one which is used.
> >>  
> > 
> > Why?
> > 
> > If each name is referenced not by name, but by a unique address,
> > then you could have duplicate names, without collision of the
> > address.  Yes?  
> 
> I'm not sure what you mean. There is no address here. This is all
> about names. 

Something must parse the names, at which point, couldn't an address be
used as computers work so well with integers?

> I was suggesting that there are two ways to combine
> namespaces, as above.
> 

I was suggesting a third.

3. Names need not be unique.  Names can be the same.  The
appropriate namespace for any name is selected by some other method,
e.g., the current directory or top-level directory of the project or
the project name or a #define, etc.

In this method, each name gets a unique address.  If the name is
duplicated, it still gets a unique address for each of the duplicated
names, since each namespace is named differently from the other.  E.g.,
one namespace ("Bob") has a partial address from a hash function of
0xBC32 and the name SS.h is assigned 0x8321 from a hash function.
Another namespace ("Chuck") has a partial address from a hash function
of 0x9450 and the name SS.h is assigned 0x8321 from the same hash
function.  So, SS.h in one namespace ("Bob") is 0xBC328321 while in the
other ("Chuck") it's 0x94508321.  SS.h doesn't collide with SS.h even
though the names are duplicated.  So, the names within namespaces do not
need to be unique and can be duplicates, but the names of the actual
namespaces would need to be unique.  I.e., while you can duplicate
SS.h in different namespaces, you can't have two "Bob" or two "Chuck"
namespaces.  Another way to think of this is that one SS.h is Bob_SS.h
while the other is Chuck_SS.h.  Unique directory paths could suffice for
"Bob" and "Chuck".  If you installed two copies of a project, the
top-level directory would need different names, e.g.,
project1/abc/cde/SS.h and project2/abc/cde/SS.h.


Rod Pemberton
-- 
feeback loop:  Russian aggression -> World complains -> Russian
paranioa -> Russian threats -> repeat

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

#3883

On 07/03/2018 11:58, Rod Pemberton wrote:
> On Tue, 6 Mar 2018 21:10:37 +0000
> James Harris <james.harris.1@gmail.com> wrote:
> 
>> On 06/03/2018 11:40, Rod Pemberton wrote:
>>> On Fri, 2 Mar 2018 21:05:12 +0000
>>> James Harris <james.harris.1@gmail.com> wrote:
>>>
>>> [dropped c.l.c]

Added it back for this one reply. Feel free to drop it again, Rod.

> 
>>>> On that, I think that to do this properly there may be a need for
>>>> what you might call "namespace algebra"! Specifically, there may
>>>> be a need for two ways to combine namespaces:
>>>>
>>>> 1. Names must be unique - i.e. no duplicates in another namespace.
>>>> 2. Names can be the same but the namespaces are ordered and the
>>>> first namespace which contains the name is the one which is used.
>>>>   
>>>
>>> Why?
>>>
>>> If each name is referenced not by name, but by a unique address,
>>> then you could have duplicate names, without collision of the
>>> address.  Yes?
>>
>> I'm not sure what you mean. There is no address here. This is all
>> about names.
> 
> Something must parse the names, at which point, couldn't an address be
> used as computers work so well with integers?

Maybe, perhaps as Unix filesystems map an arbitrary number of names to 
inode numbers, but I don't see the relevance.

> 
>> I was suggesting that there are two ways to combine
>> namespaces, as above.
>>
> 
> I was suggesting a third.
> 
> 3. Names need not be unique.  Names can be the same.  The
> appropriate namespace for any name is selected by some other method,
> e.g., the current directory or top-level directory of the project or
> the project name or a #define, etc.
> 
> In this method, each name gets a unique address.  If the name is
> duplicated, it still gets a unique address for each of the duplicated
> names, since each namespace is named differently from the other.  E.g.,
> one namespace ("Bob") has a partial address from a hash function of
> 0xBC32 and the name SS.h is assigned 0x8321 from a hash function.
> Another namespace ("Chuck") has a partial address from a hash function
> of 0x9450 and the name SS.h is assigned 0x8321 from the same hash
> function.  So, SS.h in one namespace ("Bob") is 0xBC328321 while in the
> other ("Chuck") it's 0x94508321.  SS.h doesn't collide with SS.h even
> though the names are duplicated.  So, the names within namespaces do not
> need to be unique and can be duplicates, but the names of the actual
> namespaces would need to be unique.  I.e., while you can duplicate
> SS.h in different namespaces, you can't have two "Bob" or two "Chuck"
> namespaces.  Another way to think of this is that one SS.h is Bob_SS.h
> while the other is Chuck_SS.h.  Unique directory paths could suffice for
> "Bob" and "Chuck".  If you installed two copies of a project, the
> top-level directory would need different names, e.g.,
> project1/abc/cde/SS.h and project2/abc/cde/SS.h.

That all makes sense. Are you thinking that 0xBC328321 and 0x94508321 
would be the same SS.h or would they refer to different files called 
SS.h (in different folders, Bob and Chuck)?

In terms of combining namespaces algebraically I had in mind two 
functions such as

   (union A, B, C)
   (overlay A, B, C)

The first, union, would require that names in the three namespaces, A, B 
and C would all be unique (and would throw an exception if they were not).

The second, overlay, would allow duplicate names, presenting the name 
from the first namespace which matched. For example, if B and C 
contained the name x then

   (overlay A, B, C).x

would pick B.x rather than C.x because B is listed first.

The union and overlay operations could be combined as needed, e.g.

   (overlay A, (union B, C))

In the context of specifying where to look for #include-type files each 
namespace would be a folder in the file system, and the two operations 
would be used to combine folders as needed. That's the basic idea I had 
about specifying namespaces.

Unix and Windows search paths use only an overlay-type operation in that 
names can appear more than once but the first match in the search path 
is always the one which is used.


-- 
James Harris

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

#3884

On Fri, 9 Mar 2018 01:23:14 +0000
James Harris <james.harris.1@gmail.com> wrote:

> On 07/03/2018 11:58, Rod Pemberton wrote:
> > On Tue, 6 Mar 2018 21:10:37 +0000
> > James Harris <james.harris.1@gmail.com> wrote:

> >> On 06/03/2018 11:40, Rod Pemberton wrote:  
> >>> On Fri, 2 Mar 2018 21:05:12 +0000
> >>> James Harris <james.harris.1@gmail.com> wrote:
> >>>
> >>> [dropped c.l.c]  
> 
> Added it back for this one reply. Feel free to drop it again, Rod.

Sigh, ...

> >>>> On that, I think that to do this properly there may be a need for
> >>>> what you might call "namespace algebra"! Specifically, there may
> >>>> be a need for two ways to combine namespaces:
> >>>>
> >>>> 1. Names must be unique - i.e. no duplicates in another
> >>>> namespace. 2. Names can be the same but the namespaces are
> >>>> ordered and the first namespace which contains the name is the
> >>>> one which is used. 
> >>>
> >>> Why?
> >>>
> >>> If each name is referenced not by name, but by a unique address,
> >>> then you could have duplicate names, without collision of the
> >>> address.  Yes?  
> >>
> >> I'm not sure what you mean. There is no address here. This is all
> >> about names.  
> > 
> > Something must parse the names, at which point, couldn't an address
> > be used as computers work so well with integers?  
> 
> Maybe, perhaps as Unix filesystems map an arbitrary number of names
> to inode numbers, but I don't see the relevance.

No, not the file system, but your compiler, where it distinguishes
between namespaces and names within.  Never mind.  Forget it.  Let's
move on.

> >> I was suggesting that there are two ways to combine
> >> namespaces, as above.
> >>  
> > 
> > I was suggesting a third.
> > 
> > 3. Names need not be unique.  Names can be the same.  The
> > appropriate namespace for any name is selected by some other method,
> > e.g., the current directory or top-level directory of the project or
> > the project name or a #define, etc.
> > 
> > In this method, each name gets a unique address.  If the name is
> > duplicated, it still gets a unique address for each of the
> > duplicated names, since each namespace is named differently from
> > the other.  E.g., one namespace ("Bob") has a partial address from
> > a hash function of 0xBC32 and the name SS.h is assigned 0x8321 from
> > a hash function. Another namespace ("Chuck") has a partial address
> > from a hash function of 0x9450 and the name SS.h is assigned 0x8321
> > from the same hash function.  So, SS.h in one namespace ("Bob") is
> > 0xBC328321 while in the other ("Chuck") it's 0x94508321.  SS.h
> > doesn't collide with SS.h even though the names are duplicated.
> > So, the names within namespaces do not need to be unique and can be
> > duplicates, but the names of the actual namespaces would need to be
> > unique.  I.e., while you can duplicate SS.h in different
> > namespaces, you can't have two "Bob" or two "Chuck" namespaces.
> > Another way to think of this is that one SS.h is Bob_SS.h while the
> > other is Chuck_SS.h.  Unique directory paths could suffice for
> > "Bob" and "Chuck".  If you installed two copies of a project, the
> > top-level directory would need different names, e.g.,
> > project1/abc/cde/SS.h and project2/abc/cde/SS.h.  
> 
> That all makes sense. Are you thinking that 0xBC328321 and 0x94508321 
> would be the same SS.h or would they refer to different files called 
> SS.h (in different folders, Bob and Chuck)?

Different.  Each namespace is distinct, yes? ...

> In terms of combining namespaces algebraically I had in mind two 
> functions such as
> 
>    (union A, B, C)
>    (overlay A, B, C)
>
> The first, union, would require that names in the three namespaces,
> A, B and C would all be unique (and would throw an exception if they
> were not).
>
> The second, overlay, would allow duplicate names, presenting the name 
> from the first namespace which matched. For example, if B and C 
> contained the name x then
> 
>    (overlay A, B, C).x
> would pick B.x rather than C.x because B is listed first.
> 
> The union and overlay operations could be combined as needed, e.g.
> 
>    (overlay A, (union B, C))

From the way you've defined union and overlay, as they differ the
meanings I'm familiar with, I'm taking this example to mean:

1) first, merge B and C namespaces, i.e., "union", but throw an
exception if any names within B and C are duplicated, i.e., not
"unique", and if there was an exception, then also abort the "overlay"
operation of the A namespace with the "union" of the B and C namespace

2) second, if there was no exception due to the "union" of the B and C
namespaces, then merge the A namespace with the "union" of the B and C
namespaces, then preference any duplicated names, from those within the
A namespace, over any of the duplicated names from those within the
"union" of B and C namespace, i.e., "overlay"

Is that close enough? ...

> In the context of specifying where to look for #include-type files
> each namespace would be a folder in the file system, and the two
> operations would be used to combine folders as needed. That's the
> basic idea I had about specifying namespaces.

In this regard, the "overlay" is somewhat like a mount point for a Linux
file system, but not exactly.  E.g., if drive A (or some other path)
is mounted on top of directory B, then B is hidden until drive A is
unmounted.  Any references to files in directory B depends on whether
drive A is mounted there or not.  Of course, you don't get to see the B
directory files if A is mounted.  So, it's not an actual merging
(neither "overlay" nor "union") of A and B with A files taking
precedence.

> Unix and Windows search paths use only an overlay-type operation in
> that names can appear more than once but the first match in the
> search path is always the one which is used.

Um, ...   So, I'm thinking that you'd need to re-implement the rules
for locating files within the file system.  E.g., *nix file systems
have links, which could be considered to be a simpler mechanism than
your "union" and "overlay".  So, you'd likely need something to
implement your "union" and "overlay" operations.  My guess is that to
implement this, that you'd need to create two special types of OS links
for "union" and "overlay", or you'd need to create file(s) with control
directives for use by your compiler or tool chain.

If links, one kind of link could be for your "union" and another for
your "overlay".  Their merging operations would need to be implemented
by the OS' file system and directory management software.  So, I think
this is probably out-of-the-question, as I suspect that you're not
likely to modify an OS to support this.

If file(s), the union/overlay control file(s) could be placed in any
directory as-needed, and accessed and used by your compiler or tool
chain.  Your compiler or tool chain would need to read in the
directories and implement the mergers ("union" or "overlay") within
it's own in-memory directory layout.  This would be done according to
the directives within the union/overlay control files, in order to
decide which files to access, and determine where located.  In other
words, you'd implement a file system on top of the host OS file
system within your application, while using the host OS file system to
store "instructions" about how to do that within the control files.


Rod Pemberton
-- 
feedback loop:  Russian aggression -> World complains -> Russian
paranoia -> Russian threats -> repeat

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

#3885

On Fri, 9 Mar 2018 02:28:09 -0500
Rod Pemberton <NoEmail@trraxvfeqa.prg> wrote:


In regards to,

> If file(s), the union/overlay control file(s) could be placed in any
> directory as-needed, and accessed and used by your compiler or tool
> chain.  Your compiler or tool chain would need to read in the
> directories and implement the mergers ("union" or "overlay") within
> it's own in-memory directory layout.  This would be done according to
> the directives within the union/overlay control files, in order to
> decide which files to access, and determine where located.  In other
> words, you'd implement a file system on top of the host OS file
> system within your application, while using the host OS file system to
> store "instructions" about how to do that within the control files.
> 
> 

If you're not familiar with what I'm referring to here about a
filesystem on top of a filesystem, a fairly well known example is UMSDOS
which implement a Linux filesystem on DOS using files to store the
additional information:

https://en.wikipedia.org/wiki/FAT_filesystem_and_Linux#Data_structures_of_umsdos

Of course, you could create your own filesystem for Linux at least:

https://en.wikipedia.org/wiki/Filesystem_in_Userspace


Rod Pemberton
-- 
feedback loop:  Russian aggression -> World complains -> Russian
paranoia -> Russian threats -> repeat

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

#3888

On 09/03/2018 07:28, Rod Pemberton wrote:
> On Fri, 9 Mar 2018 01:23:14 +0000
> James Harris <james.harris.1@gmail.com> wrote:
>> On 07/03/2018 11:58, Rod Pemberton wrote:
>>> On Tue, 6 Mar 2018 21:10:37 +0000
>>> James Harris <james.harris.1@gmail.com> wrote:
>>>> On 06/03/2018 11:40, Rod Pemberton wrote:
>>>>> On Fri, 2 Mar 2018 21:05:12 +0000
>>>>> James Harris <james.harris.1@gmail.com> wrote:

...

>>>> I was suggesting that there are two ways to combine
>>>> namespaces, as above.
>>>>   
>>>
>>> I was suggesting a third.
>>>
>>> 3. Names need not be unique.  Names can be the same.  The
>>> appropriate namespace for any name is selected by some other method,
>>> e.g., the current directory or top-level directory of the project or
>>> the project name or a #define, etc.
>>>
>>> In this method, each name gets a unique address.  If the name is
>>> duplicated, it still gets a unique address for each of the
>>> duplicated names, since each namespace is named differently from
>>> the other.  E.g., one namespace ("Bob") has a partial address from
>>> a hash function of 0xBC32 and the name SS.h is assigned 0x8321 from
>>> a hash function. Another namespace ("Chuck") has a partial address
>>> from a hash function of 0x9450 and the name SS.h is assigned 0x8321
>>> from the same hash function.  So, SS.h in one namespace ("Bob") is
>>> 0xBC328321 while in the other ("Chuck") it's 0x94508321.  SS.h
>>> doesn't collide with SS.h even though the names are duplicated.
>>> So, the names within namespaces do not need to be unique and can be
>>> duplicates, but the names of the actual namespaces would need to be
>>> unique.  I.e., while you can duplicate SS.h in different
>>> namespaces, you can't have two "Bob" or two "Chuck" namespaces.
>>> Another way to think of this is that one SS.h is Bob_SS.h while the
>>> other is Chuck_SS.h.  Unique directory paths could suffice for
>>> "Bob" and "Chuck".  If you installed two copies of a project, the
>>> top-level directory would need different names, e.g.,
>>> project1/abc/cde/SS.h and project2/abc/cde/SS.h.
>>
>> That all makes sense. Are you thinking that 0xBC328321 and 0x94508321
>> would be the same SS.h or would they refer to different files called
>> SS.h (in different folders, Bob and Chuck)?
> 
> Different.  Each namespace is distinct, yes? ...

Yes. Though as you've pointed out, on Unix two names can refer to the 
same file. But that's maybe irrelevant here.

> 
>> In terms of combining namespaces algebraically I had in mind two
>> functions such as
>>
>>     (union A, B, C)
>>     (overlay A, B, C)
>>
>> The first, union, would require that names in the three namespaces,
>> A, B and C would all be unique (and would throw an exception if they
>> were not).
>>
>> The second, overlay, would allow duplicate names, presenting the name
>> from the first namespace which matched. For example, if B and C
>> contained the name x then
>>
>>     (overlay A, B, C).x
>> would pick B.x rather than C.x because B is listed first.
>>
>> The union and overlay operations could be combined as needed, e.g.
>>
>>     (overlay A, (union B, C))
> 
>  From the way you've defined union and overlay, as they differ the
> meanings I'm familiar with, I'm taking this example to mean:
> 
> 1) first, merge B and C namespaces, i.e., "union", but throw an
> exception if any names within B and C are duplicated, i.e., not
> "unique", and if there was an exception, then also abort the "overlay"
> operation of the A namespace with the "union" of the B and C namespace
> 
> 2) second, if there was no exception due to the "union" of the B and C
> namespaces, then merge the A namespace with the "union" of the B and C
> namespaces, then preference any duplicated names, from those within the
> A namespace, over any of the duplicated names from those within the
> "union" of B and C namespace, i.e., "overlay"
> 
> Is that close enough? ...

Yes, exactly right.

> 
>> In the context of specifying where to look for #include-type files
>> each namespace would be a folder in the file system, and the two
>> operations would be used to combine folders as needed. That's the
>> basic idea I had about specifying namespaces.
> 
> In this regard, the "overlay" is somewhat like a mount point for a Linux
> file system, but not exactly.  E.g., if drive A (or some other path)
> is mounted on top of directory B, then B is hidden until drive A is
> unmounted.  Any references to files in directory B depends on whether
> drive A is mounted there or not.  Of course, you don't get to see the B
> directory files if A is mounted.  So, it's not an actual merging
> (neither "overlay" nor "union") of A and B with A files taking
> precedence.

The overlay operation is one that's used, AIUI, on a read-only 
multisession optical drive. Old sessions are preserved unchanged; new 
and updated directories are written to use files from current and 
previous sessions.

Incidentally, I picked the terms union and overlay off the top of my 
head. As I said earlier, I assumed there would be a set of well-known 
(and named) operations on namespaces but couldn't find any 
computer-science theory about it.

> 
>> Unix and Windows search paths use only an overlay-type operation in
>> that names can appear more than once but the first match in the
>> search path is always the one which is used.
> 
> Um, ...   So, I'm thinking that you'd need to re-implement the rules
> for locating files within the file system.  E.g., *nix file systems
> have links, which could be considered to be a simpler mechanism than
> your "union" and "overlay".  So, you'd likely need something to
> implement your "union" and "overlay" operations.  My guess is that to
> implement this, that you'd need to create two special types of OS links
> for "union" and "overlay", or you'd need to create file(s) with control
> directives for use by your compiler or tool chain.
> 
> If links, one kind of link could be for your "union" and another for
> your "overlay".  Their merging operations would need to be implemented
> by the OS' file system and directory management software.  So, I think
> this is probably out-of-the-question, as I suspect that you're not
> likely to modify an OS to support this.
> 
> If file(s), the union/overlay control file(s) could be placed in any
> directory as-needed, and accessed and used by your compiler or tool
> chain.  Your compiler or tool chain would need to read in the
> directories and implement the mergers ("union" or "overlay") within
> it's own in-memory directory layout.  This would be done according to
> the directives within the union/overlay control files, in order to
> decide which files to access, and determine where located.  In other
> words, you'd implement a file system on top of the host OS file
> system within your application, while using the host OS file system to
> store "instructions" about how to do that within the control files.

No changes to the file system would be needed. The only challenge (in 
this case) is how a program can work out which folder names to use in 
each compile command. In that, if the programmer needed only what I've 
called "overlay" then all that would be needed would be a list of 
folders in the same form which is used, at present, for a PATH variable, 
i.e. use the first match. So the mechanism is doable, but the main 
problem is knowing which folders to use. For that, I think I'll have to 
use configuration files - probably with wildcards along the following 
lines.

files A/*   isearch (overlay A/, .)

meaning for anything in folder A add two folders to the search path: the 
contents of A and "." - i.e. the contents of the folder containing A. Of 
course, such a use of wildcards would require that all source files in A 
can work with the same layering of include folders.


-- 
James Harris

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

#3889

On Fri, 9 Mar 2018 23:26:21 +0000
James Harris <james.harris.1@gmail.com> wrote:


> The overlay operation is one that's used, AIUI, on a read-only 
> multisession optical drive.

If it's read-only, how did the data get on the device? erasable with
switch? write-once? ...

Do you mean media something like write-once, but capable of writing
multiple sessions?  E.g., like write-once CDROMs, but with an
incremental file system, like UDF?

> The overlay operation is one that's used, AIUI, on a read-only 
> multisession optical drive. Old sessions are preserved unchanged; new 
> and updated directories are written to use files from current and 
> previous sessions.

That sounds like incremental backups of files.

> Incidentally, I picked the terms union and overlay off the top of my 
> head. As I said earlier, I assumed there would be a set of well-known 
> (and named) operations on namespaces but couldn't find any 
> computer-science theory about it.

I suspect you'd be looking at set theory to answer those questions,
and perhaps some Boolean algebra.

https://en.wikipedia.org/wiki/Set_theory
https://en.wikipedia.org/wiki/Boolean_algebra

You may need to refer to Venn and Euler diagrams too.

https://en.wikipedia.org/wiki/Venn_diagram
https://en.wikipedia.org/wiki/Euler_diagram


Rod Pemberton
-- 
feedback loop:  Russian aggression -> World complains -> Russian
paranoia -> Russian threats -> repeat

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

#3891

On 11/03/2018 11:44, Rod Pemberton wrote:
> On Fri, 9 Mar 2018 23:26:21 +0000
> James Harris <james.harris.1@gmail.com> wrote:
> 
> 
>> The overlay operation is one that's used, AIUI, on a read-only
>> multisession optical drive.
> 
> If it's read-only, how did the data get on the device? erasable with
> switch? write-once? ...
> 
> Do you mean media something like write-once, but capable of writing
> multiple sessions?  E.g., like write-once CDROMs, but with an
> incremental file system, like UDF?

Yes, perhaps the read-only part was extra to requirements. Multisession 
was all that was needed.

> 
>> The overlay operation is one that's used, AIUI, on a read-only
>> multisession optical drive. Old sessions are preserved unchanged; new
>> and updated directories are written to use files from current and
>> previous sessions.
> 
> That sounds like incremental backups of files.

FWIW the overlay operation has an important difference when files are 
deleted. Because the original file and the original directory entry 
still exist, to 'delete' a file from a later session requires a 
directory entry (in the directory for that later session) which names 
the file and says it has been deleted.


-- 
James Harris

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

#3893

On Mon, 12 Mar 2018 21:59:28 +0000
James Harris <james.harris.1@gmail.com> wrote:

> >> The overlay operation is one that's used, AIUI, on a read-only
> >> multisession optical drive. Old sessions are preserved unchanged;
> >> new and updated directories are written to use files from current
> >> and previous sessions.  
> > 
> > That sounds like incremental backups of files.  
> 
> FWIW the overlay operation has an important difference when files are 
> deleted. Because the original file and the original directory entry 
> still exist, to 'delete' a file from a later session requires a 
> directory entry (in the directory for that later session) which names 
> the file and says it has been deleted.
> 

I want to say the old CBM DOS (disk operating system) which originated
from CBM mainframes, used by Commodore's disk drives for their home
computers, e.g., C64, VIC20, simply marked directory entries as
deleted.  However, I'd need to actually go look it up to say for sure.
Maybe, it was MS-DOS instead? ...


Rod Pemberton
-- 
feedback loop:  Russian aggression -> World complains -> Russian
paranoia -> Russian threats -> repeat

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

#3897

On 14/03/2018 05:45, Rod Pemberton wrote:
> On Mon, 12 Mar 2018 21:59:28 +0000
> James Harris <james.harris.1@gmail.com> wrote:
> 
>>>> The overlay operation is one that's used, AIUI, on a read-only
>>>> multisession optical drive. Old sessions are preserved unchanged;
>>>> new and updated directories are written to use files from current
>>>> and previous sessions.
>>>
>>> That sounds like incremental backups of files.
>>
>> FWIW the overlay operation has an important difference when files are
>> deleted. Because the original file and the original directory entry
>> still exist, to 'delete' a file from a later session requires a
>> directory entry (in the directory for that later session) which names
>> the file and says it has been deleted.
>>
> 
> I want to say the old CBM DOS (disk operating system) which originated
> from CBM mainframes, used by Commodore's disk drives for their home
> computers, e.g., C64, VIC20, simply marked directory entries as
> deleted.  However, I'd need to actually go look it up to say for sure.
> Maybe, it was MS-DOS instead? ...

Like you, I've heard about such things and I'm sure 'overlaying' 
namespaces is not new. That's why I assumed there would be some 
pre-existing computer-science theory about a namespace combination 
techniques.

A pre-existing theory would deal with subtleties. For example, in

   (overlay P, Q, R)

if P, Q and R were normal folders then none of them could contain a 
'deleted' entry (assuming normal folders do not contain such things). 
But the result of the overlay operation would have to be able to contain 
such entries.

If Q, say, were itself an overlay of other folders such as

   Q = (overlay, S, T)

then the situation changes in that Q /could/ contain 'deleted' entries 
and they would have to be propagated appropriately in the earlier 
expression. A file called x which Q has as 'deleted' probably should not 
obscure a file called x in R, for example. So deleted and non-deleted 
files would need to be handled separately.

As I say, I assumed there would be pre-existing theories about this stuff.


-- 
James Harris

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

#3868

On Fri, 2 Mar 2018 21:05:12 +0000
James Harris <james.harris.1@gmail.com> wrote:

[c.l.c. dropped]

> If one thinks of each folder as a namespace (reasons below), the
> query is about how to tell a compiler which namespaces to search in
> order to find #include targets.

How is this different from a bunch of nested #ifdefs, which check for a
compiler specific #define, then #include a bunch of include files for
the specific compiler? ...

> They would probably normally be
> specified on the command line with a -I or the like,

defined with -D


Rod Pemberton
-- 
feeback loop:  Russian aggression -> World complains -> Russian
paranioa -> Russian threats -> repeat

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

#3870

On 06/03/2018 11:40, Rod Pemberton wrote:
> On Fri, 2 Mar 2018 21:05:12 +0000
> James Harris <james.harris.1@gmail.com> wrote:
> 
> [c.l.c. dropped]
> 
>> If one thinks of each folder as a namespace (reasons below), the
>> query is about how to tell a compiler which namespaces to search in
>> order to find #include targets.
> 
> How is this different from a bunch of nested #ifdefs, which check for a
> compiler specific #define, then #include a bunch of include files for
> the specific compiler? ...

A key point is that it should work with any compiler or assembler.

> 
>> They would probably normally be
>> specified on the command line with a -I or the like,
> 
> defined with -D

If I understand, that would define symbols but it wouldn't tell the 
preprocessor where to look for include files.


-- 
James Harris

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

#3878

On Tue, 6 Mar 2018 21:20:36 +0000
James Harris <james.harris.1@gmail.com> wrote:

> On 06/03/2018 11:40, Rod Pemberton wrote:
> > On Fri, 2 Mar 2018 21:05:12 +0000
> > James Harris <james.harris.1@gmail.com> wrote:
> > 
> > [c.l.c. dropped]

> >> If one thinks of each folder as a namespace (reasons below), the
> >> query is about how to tell a compiler which namespaces to search in
> >> order to find #include targets.  
> > 
> > How is this different from a bunch of nested #ifdefs, which check
> > for a compiler specific #define, then #include a bunch of include
> > files for the specific compiler? ...  
> 
> A key point is that it should work with any compiler or assembler.

Is this project encompassing any or all of the following?

a) make program
b) makefile or sh build script or DOS .bat etc
c) preprocessor

> >> They would probably normally be
> >> specified on the command line with a -I or the like,  
> > 
> > defined with -D  
> 
> If I understand, that would define symbols but it wouldn't tell the 
> preprocessor where to look for include files.
> 
> 

That's what the nested #ifdefs do with the -D defines or #defines.
(example in another post)


Rod Pemberton
-- 
feeback loop:  Russian aggression -> World complains -> Russian
paranioa -> Russian threats -> repeat

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

#3887

On 07/03/2018 11:58, Rod Pemberton wrote:
> On Tue, 6 Mar 2018 21:20:36 +0000
> James Harris <james.harris.1@gmail.com> wrote:
> 
>> On 06/03/2018 11:40, Rod Pemberton wrote:
>>> On Fri, 2 Mar 2018 21:05:12 +0000
>>> James Harris <james.harris.1@gmail.com> wrote:
>>>
>>> [c.l.c. dropped]
> 
>>>> If one thinks of each folder as a namespace (reasons below), the
>>>> query is about how to tell a compiler which namespaces to search in
>>>> order to find #include targets.
>>>
>>> How is this different from a bunch of nested #ifdefs, which check
>>> for a compiler specific #define, then #include a bunch of include
>>> files for the specific compiler? ...
>>
>> A key point is that it should work with any compiler or assembler.
> 
> Is this project encompassing any or all of the following?
> 
> a) make program
> b) makefile or sh build script or DOS .bat etc
> c) preprocessor

What I have in mind would replace configure scripts, make, and build 
scripts but not existing preprocessors.

> 
>>>> They would probably normally be
>>>> specified on the command line with a -I or the like,
>>>
>>> defined with -D
>>
>> If I understand, that would define symbols but it wouldn't tell the
>> preprocessor where to look for include files.
>>
>>
> 
> That's what the nested #ifdefs do with the -D defines or #defines.
> (example in another post)

OK.


-- 
James Harris

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

Page 1 of 6  [1] 2 3 4 5 6  Next page →

Back to top | Article view | comp.lang.misc

csiph-web