Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.misc > #3851 > unrolled thread
| Started by | James Harris <james.harris.1@gmail.com> |
|---|---|
| First post | 2018-03-01 14:40 +0000 |
| Last post | 2018-03-14 13:39 +0100 |
| Articles | 20 on this page of 110 — 11 participants |
Back to article view | Back to comp.lang.misc
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 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2018-03-01 11:11 -0500 |
| Message-ID | <add38470-14ca-b154-7b47-abd50e7b3473@verizon.net> |
| In reply to | #3851 |
On 03/01/2018 09:40 AM, 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 sequences in both forms of header names are mapped in an implementation-defined manner to headers or external source file names as specified in 6.10.2." (6.4.7p2) On every implementation that I can remember using, that "implementation-defined" mapping would map "PP/SS.h" to a file named SS.h in a subdirectory named PP of one of the directories on the current search path. Of course, most of the systems I've ever used were Unix-like, so it may be different on other systems. Many Unix-standard headers rely on this, having names like "sys/socket.h". In particular, it seems likely that it worked differently on the VMS systems I used nearly 3 decades ago - but I don't remember the details. > ... the compiler has to be told about folder PP so it looks in it for > the header. That's not the only option on the systems I'm familiar with - but the C standard itself says nothing about either method of letting the compiler know which directory to search. > ... 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? Most of the compilers I've ever used (which isn't a particularly large variety - but they are very popular) will accept a -L option to add specified directories to the search path. The POSIX "make" command has default rules that include $(CPPFLAGS) as one of the command line arguments when compiling; the CPP in the name reflects it's traditional use as a place for options that are relevant to the C pre-processor, which are mainly -L options. You can set CPPFLAGS in your makefile - otherwise, it's filled in by default from the CPPFLAGS environment variable.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2018-03-01 13:51 -0500 |
| Message-ID | <21bda30d-7b68-03c2-e38a-37da70cac14c@verizon.net> |
| In reply to | #3853 |
On 03/01/2018 11:11 AM, James R. Kuyper wrote: ... > Most of the compilers I've ever used (which isn't a particularly large > variety - but they are very popular) will accept a -L option to add > specified directories to the search path. The POSIX "make" command has > default rules that include $(CPPFLAGS) as one of the command line > arguments when compiling; the CPP in the name reflects it's traditional > use as a place for options that are relevant to the C pre-processor, > which are mainly -L options. You can set CPPFLAGS in your makefile - What I meant, of course, was "-I", not "-L".
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2018-03-03 09:48 +0000 |
| Message-ID | <p7dr28$pd7$1@dont-email.me> |
| In reply to | #3853 |
On 01/03/2018 16:11, James R. Kuyper wrote: > On 03/01/2018 09:40 AM, 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 sequences in both forms of header names are mapped in an > implementation-defined manner to headers or external source file names > as specified in 6.10.2." (6.4.7p2) > > On every implementation that I can remember using, that > "implementation-defined" mapping would map "PP/SS.h" to a file named > SS.h in a subdirectory named PP of one of the directories on the current > search path. Of course, most of the systems I've ever used were > Unix-like, so it may be different on other systems. Many Unix-standard > headers rely on this, having names like "sys/socket.h". In particular, > it seems likely that it worked differently on the VMS systems I used > nearly 3 decades ago - but I don't remember the details. Yeah, my mistake. I was originally posting to comp.lang.misc about a theoretical problem and found myself using C for the examples. Since the issue applied to C compilation I added comp.lang.c. The issue remains, however, which is in a project of arbitrary size how to generate complete compiler-invocation commands programmatically, making sure that all the necessary 'include folders' are provided (with switches such as -I). For this purpose, one could assume either that #include lines omit folder names or that if they do give folder names they are still intended to be relative to an unspecified point, requiring the preprocessor to carry out a search in the form you mention. The problem is in any particular compile how to know which folder names to use. All I can think of just now is to have a configuration file which says which 'include folders' to use for which source files. -- James Harris
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2018-03-03 12:25 +0000 |
| Message-ID | <p7e47k$sua$1@dont-email.me> |
| In reply to | #3851 |
On 01/03/2018 22:46, Jorgen Grahn wrote: > On Thu, 2018-03-01, 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. 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 - > > No sane real project is scattered around the file system: it lives > under a well-defined top-level directory. I agree. But a program should cope with input insanity! In other words, the problem in this case is how to generate compile commands, making no assumptions about how a programmer would have laid out the source tree. To be clear, the idea is to have the compile commands generated by a program. It would have to work with however the programmer chose to arrange the source code. > >> 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. > > I don't see why that would be needed, but agreed: it would be > terrible. > >> 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, > > Why not? > > Here's what I do, and it does scale. > > pp/ # project directory > pp/1.c # some source file > pp/2.h # some header > > pp/sub/ # some more or less well-defined subsystem > pp/sub/1.c # some source file > pp/sub/2.h # some header > > pp/test/ # unit tests > pp/test/1.c > > Files refer to headers on their own level with #include "2.h". > Files in pp/ refer to files in pp/sub/ with #include "sub/2.h". > Files in pp/sub/ don't refer to files in pp/ at all. > > The unit tests treat pp/ as if it was an installed library, > and do #include <2.h>, #include <sub/2.h>. > > It's also easy to write a single Makefile (pp/Makefile) for this > scheme. The only thing you need to do is provide one -I option when > building the unit tests. > > It may be more difficult if you need to support really exotic > platforms (which perhaps don't have directories) or if you need to > do cross-compilation (so everything but the unit tests is build > twice, using different compilers). Thanks for explaining your setup. I take it that all sources under pp/ can be compiled with the same set of -I folders. That may not be the case, in general, of course. When you link to form a load module do you similarly use a project-wide set of library folders (the -L folders to a typical linker)? > >> 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. > > That's the first time you brought up interdependencies between > multiple projects, but I sense that that was what you were thinking > about all along. > > My advice is: /don't do it/. I've never seen it being done > successfully, without a hefty cost in terms of lost productivity. If > you need project A to depend on project B, make it depend on library B > being installed onto the system instead, the way you depend on the > standard library or third-party libraries. Understood, though I have to say I am more inclined to split existing packages into smaller ones than to make each one more independent. Besides, this compiler-driver idea is meant to be part of a bigger system - which would probably go a bit off topic just now. But a compile should, basically, use the most recent updates to any source file. -- James Harris
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-03-03 15:32 +0000 |
| Message-ID | <mezmC.5954$4j2.1021@fx35.am4> |
| In reply to | #3859 |
On 03/03/2018 12:25, James Harris wrote: > On 01/03/2018 22:46, Jorgen Grahn wrote: >> No sane real project is scattered around the file system: it lives >> under a well-defined top-level directory. (Aren't Linux files disseminated like that anyway?) > To be clear, the idea is to have the compile commands generated by a > program. That seems to be just moving the problem elsewhere. And having compile commands, in the form of generated makefiles, seems common. (Which is not satisfactory: what to make of all this: https://pastebin.com/raw/McLRQgzS? I know there are hundreds of .c files involved, but where are they in this file?) What is the input to that program? Somewhere, something or someone needs to know exactly what files are to be compiled, exactly where the include files are, and exactly how to compose the various outputs into the one or more executables, libraries etc that comprise the result. > When you link to form a load module do you similarly use a project-wide > set of library folders (the -L folders to a typical linker)? These days I use a linker where /everything/ has to be specified explicitly. Otherwise, various compiler systems will all do there own thing, and you may or may not need to specify the language runtime, or the OS libraries such as gdi32, or it might or might not need .lib or .a or .dll or .so. It seems more effort but then you always know exactly what is happening. If a library can't be found, then you will know why because either you forget to specify it, you gave the wrong path, or it doesn't exist. It will not be a mystery. I would not use a command like -L, which in my experience never worked properly anyway. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2018-03-04 07:52 +0000 |
| Message-ID | <slrnp9n9ei.eu5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #3860 |
["Followup-To:" header set to comp.lang.c.] On Sat, 2018-03-03, bartc wrote: > On 03/03/2018 12:25, James Harris wrote: >> On 01/03/2018 22:46, Jorgen Grahn wrote: > >>> No sane real project is scattered around the file system: it lives >>> under a well-defined top-level directory. > > (Aren't Linux files disseminated like that anyway?) We're talking about the source code for some project, so no. When you clone a git repo, do you get one top-level directory or several? /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2018-03-04 08:43 +0000 |
| Message-ID | <p7gbjm$quq$1@dont-email.me> |
| In reply to | #3860 |
On 03/03/2018 15:32, bartc wrote: > On 03/03/2018 12:25, James Harris wrote: >> On 01/03/2018 22:46, Jorgen Grahn wrote: > >>> No sane real project is scattered around the file system: it lives >>> under a well-defined top-level directory. > > (Aren't Linux files disseminated like that anyway?) That was Jorgen's comment rather than mine but AISI there is a difference. When you say "disseminated" I presume you are thinking about how finished apps are distributed and installed whereas here the query is about how source code is laid out. > > >> To be clear, the idea is to have the compile commands generated by a >> program. > > That seems to be just moving the problem elsewhere. And having compile > commands, in the form of generated makefiles, seems common. The whole make infrastructure is brilliant, IMO, but it does have some weaknesses: 1. It is more than awkward at handling dependencies which are produced on the fly. That leads to many makefiles having to split the operations so you might see make depend make The second command uses the dependency files produced by the first. It would be better to have that stuff handled automatically. 2. I would prefer the commands run to be printed only when they fail in some way, i.e. output like this would be handy command <errcode> stderr output but only when the command returned a non-zero error code or wrote something to stderr. 3. The make command is, if anything, too flexible for building programs, and that leads to some crazy makefiles. Rather than have that flexibility in each makefile it may be better to have some universal rules to which limited but sufficient tweaks can be applied. 4. Finally, make is a security risk. When you run make on someone else's makefile you often don't know which commands it will run under your userid. That's not to have a go at make. I think it's great. But that list maybe explains some of the reasons why I wanted to write a custom program builder. > > (Which is not satisfactory: what to make of all this: > https://pastebin.com/raw/McLRQgzS? I know there are hundreds of .c files > involved, but where are they in this file?) > > What is the input to that program? Somewhere, something or someone needs > to know exactly what files are to be compiled, exactly where the include > files are, and exactly how to compose the various outputs into the one > or more executables, libraries etc that comprise the result. That file well illustrates my points about make being too flexible and a security risk. As to where the .c files are mentioned, perhaps some of the included makefiles would give a clue. The mkrules.mk file may do that by scanning the directory tree based on variables which have been defined at the time that it is included. > >> When you link to form a load module do you similarly use a project-wide >> set of library folders (the -L folders to a typical linker)? > > These days I use a linker where /everything/ has to be specified > explicitly. Me too. Again, don't you think that much of that should be generatable by a program? > Otherwise, various compiler systems will all do there own > thing, and you may or may not need to specify the language runtime, or > the OS libraries such as gdi32, or it might or might not need .lib or .a > or .dll or .so. > > It seems more effort but then you always know exactly what is happening. > If a library can't be found, then you will know why because either you > forget to specify it, you gave the wrong path, or it doesn't exist. It > will not be a mystery. > > I would not use a command like -L, which in my experience never worked > properly anyway. > -- James Harris
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2018-03-05 07:58 +0000 |
| Message-ID | <slrnp9pu5k.eu5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #3862 |
(Crossposting since everyone else in the thread insists on it.)
On Sun, 2018-03-04, James Harris wrote:
...
> The whole make infrastructure is brilliant, IMO, but it does have some
> weaknesses:
>
> 1. It is more than awkward at handling dependencies which are produced
> on the fly. That leads to many makefiles having to split the operations
> so you might see
>
> make depend
> make
>
> The second command uses the dependency files produced by the first. It
> would be better to have that stuff handled automatically.
Others thought so too, so there's a way to do it (at least if you use
gcc or clang). See e.g. this Makefile of mine:
https://github.com/kjgrahn/groblad/blob/master/Makefile
Or
* Paul D. Smith: Auto-Dependency Generation
http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/
> 2. I would prefer the commands run to be printed only when they fail in
> some way, i.e. output like this would be handy
>
> command <errcode>
> stderr output
>
> but only when the command returned a non-zero error code or wrote
> something to stderr.
I think you can get that, but you have to write it yourself, in the
same way that e.g. the Linux kernel Makefile just writes
CC foo.c
LD libfoo.a
instead of the full commands by default.
Personally I want to see what's happening, especially during
incremental builds ("what needs to rebuild after the changes I
made?").
> 3. The make command is, if anything, too flexible for building programs,
> and that leads to some crazy makefiles.
No, incompetence and indifference leads to crazy makefiles.
> Rather than have that flexibility in each makefile it may be better
> to have some universal rules to which limited but sufficient tweaks
> can be applied.
That's not an original idea: I think that's the reason cmake, qmake
and so on exist. You may want to investigate them.
Those also (try to) let you split your projects into independent
sub-projects. For cmake that works reasonably well, IME.
> 4. Finally, make is a security risk. When you run make on someone else's
> makefile you often don't know which commands it will run under your userid.
What about the thing you build -- isn't that a security risk, too?
Because I assume you want to run it eventually.
I see no way around this with any build tool. Although you can build
in some sandbox, e.g. a Docker container on Linux.
> That's not to have a go at make. I think it's great. But that list maybe
> explains some of the reasons why I wanted to write a custom program
> builder.
Your goals are a bit unclear to me, so I won't comment on that.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2018-03-06 21:37 +0000 |
| Message-ID | <p7n1m7$ei6$1@dont-email.me> |
| In reply to | #3864 |
On 05/03/2018 07:58, Jorgen Grahn wrote:
> (Crossposting since everyone else in the thread insists on it.)
>
> On Sun, 2018-03-04, James Harris wrote:
> ...
>> The whole make infrastructure is brilliant, IMO, but it does have some
>> weaknesses:
>>
>> 1. It is more than awkward at handling dependencies which are produced
>> on the fly. That leads to many makefiles having to split the operations
>> so you might see
>>
>> make depend
>> make
>>
>> The second command uses the dependency files produced by the first. It
>> would be better to have that stuff handled automatically.
>
> Others thought so too, so there's a way to do it (at least if you use
> gcc or clang). See e.g. this Makefile of mine:
> https://github.com/kjgrahn/groblad/blob/master/Makefile
>
> Or
>
> * Paul D. Smith: Auto-Dependency Generation
> http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/
Thanks. Yes, I know. I spent some hours working on this a few years ago.
It was nightmarish. I think I tried two published solutions and one of
my own. All had failings of one sort or another. Can't remember the
details now but IIRC I concluded the make system is not designed to
process dependencies after it has started executing commands. As for
gcc, I didn't want to depend on a particular version of make or a
particular compiler, and this was to work with an assembler as well as a
compiler.
>
>> 2. I would prefer the commands run to be printed only when they fail in
>> some way, i.e. output like this would be handy
>>
>> command <errcode>
>> stderr output
>>
>> but only when the command returned a non-zero error code or wrote
>> something to stderr.
>
> I think you can get that, but you have to write it yourself, in the
> same way that e.g. the Linux kernel Makefile just writes
>
> CC foo.c
> LD libfoo.a
>
> instead of the full commands by default.
>
> Personally I want to see what's happening, especially during
> incremental builds ("what needs to rebuild after the changes I
> made?").
Noted. A command-line switch could allow a choice.
>
>> 3. The make command is, if anything, too flexible for building programs,
>> and that leads to some crazy makefiles.
>
> No, incompetence and indifference leads to crazy makefiles.
Sure, but sensible people don't get to write all makefiles. Software can
be distributed with makefiles which are dangerously Gordian!
>
>> Rather than have that flexibility in each makefile it may be better
>> to have some universal rules to which limited but sufficient tweaks
>> can be applied.
>
> That's not an original idea: I think that's the reason cmake, qmake
> and so on exist. You may want to investigate them.
>
> Those also (try to) let you split your projects into independent
> sub-projects. For cmake that works reasonably well, IME.
Thanks. I'll take a look.
>
>> 4. Finally, make is a security risk. When you run make on someone else's
>> makefile you often don't know which commands it will run under your userid.
>
> What about the thing you build -- isn't that a security risk, too?
> Because I assume you want to run it eventually.
On Windows or Unix, yes, but they are not all OSes. A sane OS would
execute binaries in a cocoon.
>
> I see no way around this with any build tool. Although you can build
> in some sandbox, e.g. a Docker container on Linux.
>
>> That's not to have a go at make. I think it's great. But that list maybe
>> explains some of the reasons why I wanted to write a custom program
>> builder.
>
> Your goals are a bit unclear to me, so I won't comment on that.
>
> /Jorgen
>
--
James Harris
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2018-03-07 21:02 +0000 |
| Message-ID | <slrnpa0kqc.eu5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #3871 |
On Tue, 2018-03-06, James Harris wrote: > On 05/03/2018 07:58, Jorgen Grahn wrote: >> (Crossposting since everyone else in the thread insists on it.) >> >> On Sun, 2018-03-04, James Harris wrote: >> ... >>> The whole make infrastructure is brilliant, IMO, but it does have some >>> weaknesses: >>> >>> 1. It is more than awkward at handling dependencies which are produced >>> on the fly. That leads to many makefiles having to split the operations >>> so you might see >>> >>> make depend >>> make >>> >>> The second command uses the dependency files produced by the first. It >>> would be better to have that stuff handled automatically. >> >> Others thought so too, so there's a way to do it (at least if you use >> gcc or clang). See e.g. this Makefile of mine: >> https://github.com/kjgrahn/groblad/blob/master/Makefile >> >> Or >> >> * Paul D. Smith: Auto-Dependency Generation >> http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/ > > Thanks. Yes, I know. I spent some hours working on this a few years ago. > It was nightmarish. I think I tried two published solutions and one of > my own. All had failings of one sort or another. Ok. Well, it works very nicely for me (see the Github link above). > Can't remember the > details now but IIRC I concluded the make system is not designed to > process dependencies after it has started executing commands. I'm under the impression that Gnu Make /does/ support this, and the Smith paper says so too. What I /have/ had problems with has been recursive dependencies via generated header files. I cannot remember the details, but sent a memo to myself never to let generated code into the middle of the dependency graph. > As for gcc, I didn't want to depend on a particular version of make > or a particular compiler, and this was to work with an assembler as > well as a compiler. Oh. Well, that would certainly explain your problems. Not the assembly part I think, but the lack of gcc/clang and more importantly a full-featured Make. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-03-05 15:29 +0000 |
| Message-ID | <6ndnC.194933$g34.50977@fx20.am4> |
| In reply to | #3862 |
On 04/03/2018 08:43, James Harris wrote:
> On 03/03/2018 15:32, bartc wrote:
>> These days I use a linker where /everything/ has to be specified
>> explicitly.
>
> Me too. Again, don't you think that much of that should be generatable
> by a program?
There still needs to be some input to the program; where does that
exist, and in what format?
I'd thought my own projects were small and simple compared with some of
the stuff I come across. But they present some challenges of their own.
Normally my IDE takes care of the details (it is rather crude but it
does the job), but if I wanted someone else to build my project, I
wouldn't want to inflict my crummy home-made tools on them.
So what I've done in the past, is gone to some effort to bundle the
project into a single C source file, with no headers or include files.
Then someone can build it using:
gcc -m64 program.c -oprogram.exe
or equivalent using their C compiler.
But this is not satisfactory either if someone wants to do anything else
than just create the executable (for Windows, I can just supply the
executable anyway). And it is not the true source code (which is not in C).
So I can envisage an intermediate representation of the project, which
can be just a script (even a Windows batch file would do), showing each
invocation of each program that is needed. Output from a log file might
work as well.
Then someone will get an idea of what is involved, and can adapt as needed.
Or the representation can just be in English, which lists the files (in
the correct if that is important), where they might be located, the
programs needed to be run on them, and the variations used in different
configurations.
Actually, here is attempt at such a batch file:
https://pastebin.com/raw/UeTNgxkz.
This worked, but as it is will only build one configuration. But enough
info is present to give a picture of what the build process looks like,
what files are involved, and how they are structured.
(It's challenging also as the source files are not C, and it doesn't use
a mainstream compiler. Another complication is that the files must be
compiled in a certain order because of how the module system works.)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | rugxulo@gmail.com |
|---|---|
| Date | 2018-03-06 18:23 -0800 |
| Message-ID | <8bc2a418-3d40-4009-8a31-eb43ccb67cf4@googlegroups.com> |
| In reply to | #3865 |
Hi, On Monday, March 5, 2018 at 9:29:08 AM UTC-6, Bart wrote: > On 04/03/2018 08:43, James Harris wrote: > > On 03/03/2018 15:32, bartc wrote: I generally dislike makefiles, they are usually system specific and prone to breakage. But they are fairly configurable, if done correctly. Also, the main advantage that everyone brags about is speed. But I'd rather have a slow, simple shell script that always works by default than a fast, configurable makefile that is hard (or impossible) to use. But a lot of complexity is outside of the makefile itself, i.e. system tools or third-party dependencies. Plus, a heavily-modified project is less likely to stabilize in build process until everything else calms down. > So I can envisage an intermediate representation of the project, which > can be just a script (even a Windows batch file would do), showing each > invocation of each program that is needed. Output from a log file might > work as well. If the project already has a working makefile, just run make but redirect output to file. (That's assuming non-silent compilation, some makes have switches to override silent or non-silent/noisy modes.) Then, manually convert that to .BAT or .sh or whatever. Bam, done. Similar to your .BAT below, I've also done similarly for various minor projects. > Then someone will get an idea of what is involved, and can adapt as needed. So, a simple shell script to bootstrap? > Or the representation can just be in English, which lists the files (in > the correct if that is important), where they might be located, the > programs needed to be run on them, and the variations used in different > configurations. Typically that's a file called README.pc or INSTALL or whatever. > Actually, here is attempt at such a batch file: > https://pastebin.com/raw/UeTNgxkz. > > This worked, but as it is will only build one configuration. But enough > info is present to give a picture of what the build process looks like, > what files are involved, and how they are structured. You can improve simple .BATs to where they halfway work like makefiles. So .BATs (and .sh) aren't too bad overall, but usually they are too simple. Granted, makefiles are too complex, so pick your poison! Sometimes makefiles are better because they can be (barely) massaged into cross-platform. Similarly, .BAT isn't really portable either, so you have to be very very careful. I'm no pro, but I imagine that serious projects have maintainers for various ports, people who test various platforms and tools, etc. So, if enough people want to kick the tires for a specific platform, that helps a lot (and doesn't force one person to know or do everything perfectly by default). So such projects tend to standardize on compiler, tools, targets, etc. It really does depend on host platform whether relying on xyz is well-supported or a good idea at all. You can't blindly rely on much to just magically work "everywhere". (It's somewhat bad taste to rely on GNU tools on non-GNU systems when similar system tools already exist and work well enough.) > (It's challenging also as the source files are not C, and it doesn't use > a mainstream compiler. Another complication is that the files must be > compiled in a certain order because of how the module system works.) It helps when your language has built-in dependency tracking and proper modules, etc. But some implementations, even for these languages, omit such support due to bugs or lack of time, etc. There is no quick fix. But simplicity and avoiding too many non-standard tools is wise.
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2018-03-07 04:54 +0000 |
| Message-ID | <p7nrb7$ttc$1@dont-email.me> |
| In reply to | #3865 |
On 05/03/2018 15:29, bartc wrote: > On 04/03/2018 08:43, James Harris wrote: >> On 03/03/2018 15:32, bartc wrote: > >>> These days I use a linker where /everything/ has to be specified >>> explicitly. >> >> Me too. Again, don't you think that much of that should be generatable >> by a program? > > There still needs to be some input to the program; where does that > exist, and in what format? Funny you should ask that. Assuming we are talking about the same thing I've been wrestling with that exact issue. And I think I am getting somewhere - as follows. The basic requirement is that the program which runs compilers and linkers (i.e. the replacement for make, which I'll call the 'compiler driver') knows exactly what command to run each time. For security, the programs it is allowed to invoke cannot not be part of the project as distributed but have to be specified locally. But there are also some settings which will need to be supplied with the project itself. Therefore there seems to be a need for config files to exist in three places: 1. System-wide config in /etc on Unix (and %AppData% or whatever it's called on Windows). 2. User-chosen config in ~ on Unix (and %Home% or whatever the home directory is called on Windows). (At least one of (1) or (2) would need to exist but probably both would, with any user-chosen config taking precedence over any system-wide config when the compiler driver were run by a specific user.) 3. Project-specific config in the project itself. This latter config could all be in one file at the root of the project file tree or it could conceivably be split so that some is in the root and some is lower down the tree. For security, the programs which the compiler driver would invoke would all be in places (1) and (2). By contrast, the description of what files need what treatment would all be in (3). Basically, the type (3) config files would describe the source files in the project and the other two config files would tell the compiler driver how to convert those descriptions into compile and link commands. As to what format the files would take, I am not sure of the details but I am thinking that they would be text files which contained simple textual mappings and/or allowed expressions which updated variables, somewhat like make does. > > I'd thought my own projects were small and simple compared with some of > the stuff I come across. But they present some challenges of their own. > > Normally my IDE takes care of the details (it is rather crude but it > does the job), but if I wanted someone else to build my project, I > wouldn't want to inflict my crummy home-made tools on them. > > So what I've done in the past, is gone to some effort to bundle the > project into a single C source file, with no headers or include files. > Then someone can build it using: > > gcc -m64 program.c -oprogram.exe > > or equivalent using their C compiler. > > But this is not satisfactory either if someone wants to do anything else > than just create the executable (for Windows, I can just supply the > executable anyway). And it is not the true source code (which is not in C). > > So I can envisage an intermediate representation of the project, which > can be just a script (even a Windows batch file would do), showing each > invocation of each program that is needed. Output from a log file might > work as well. You and I are looking at the same problem, i.e. how to distribute projects. There's no simple answer, is there! You may already know but some of the Unix projects use very well developed package-distribution mechanisms where one command can download and install a given package. Such mechanisms handle all dependencies automatically. AIUI they work with pre-compiled object files rather than sources. > > Then someone will get an idea of what is involved, and can adapt as needed. > > Or the representation can just be in English, which lists the files (in > the correct if that is important), where they might be located, the > programs needed to be run on them, and the variations used in different > configurations. > > Actually, here is attempt at such a batch file: > https://pastebin.com/raw/UeTNgxkz. It's very easy to read - which makes a nice change from most makefiles - but it is, of course, very specific and very manual. > > This worked, but as it is will only build one configuration. But enough > info is present to give a picture of what the build process looks like, > what files are involved, and how they are structured. > > (It's challenging also as the source files are not C, and it doesn't use > a mainstream compiler. Another complication is that the files must be > compiled in a certain order because of how the module system works.) > -- James Harris
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2018-03-07 00:33 -0600 |
| Message-ID | <pm1v9d5d2cgpk5i1b5nov3olg2j260ijdf@4ax.com> |
| In reply to | #3873 |
On Wed, 7 Mar 2018 04:54:59 +0000, James Harris <james.harris.1@gmail.com> wrote: >On 05/03/2018 15:29, bartc wrote: >> On 04/03/2018 08:43, James Harris wrote: >>> On 03/03/2018 15:32, bartc wrote: >> >>>> These days I use a linker where /everything/ has to be specified >>>> explicitly. >>> >>> Me too. Again, don't you think that much of that should be generatable >>> by a program? >> >> There still needs to be some input to the program; where does that >> exist, and in what format? > >Funny you should ask that. Assuming we are talking about the same thing >I've been wrestling with that exact issue. And I think I am getting >somewhere - as follows. > >The basic requirement is that the program which runs compilers and >linkers (i.e. the replacement for make, which I'll call the 'compiler >driver') knows exactly what command to run each time. For security, the >programs it is allowed to invoke cannot not be part of the project as >distributed but have to be specified locally. But there are also some >settings which will need to be supplied with the project itself. It's not that uncommon to have a program that's built as part of the build needing to be run to support a later part of a build. For example, there's a parser for the grammar definition for an interpreter in one of our products. It's a C++ program. It gets built, then run against the grammar definition file(s) for the interpreter, and outputs some .cpp and .h files, which are then compiled into things later in the build. You probably need to make at least some sort of way to define an exception to that rule.
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2018-03-07 09:55 +0000 |
| Message-ID | <p7ocuk$vjq$1@dont-email.me> |
| In reply to | #3874 |
On 07/03/2018 06:33, Robert Wessel wrote: > On Wed, 7 Mar 2018 04:54:59 +0000, James Harris > <james.harris.1@gmail.com> wrote: > >> On 05/03/2018 15:29, bartc wrote: >>> On 04/03/2018 08:43, James Harris wrote: >>>> On 03/03/2018 15:32, bartc wrote: >>> >>>>> These days I use a linker where /everything/ has to be specified >>>>> explicitly. >>>> >>>> Me too. Again, don't you think that much of that should be generatable >>>> by a program? >>> >>> There still needs to be some input to the program; where does that >>> exist, and in what format? >> >> Funny you should ask that. Assuming we are talking about the same thing >> I've been wrestling with that exact issue. And I think I am getting >> somewhere - as follows. >> >> The basic requirement is that the program which runs compilers and >> linkers (i.e. the replacement for make, which I'll call the 'compiler >> driver') knows exactly what command to run each time. For security, the >> programs it is allowed to invoke cannot not be part of the project as >> distributed but have to be specified locally. But there are also some >> settings which will need to be supplied with the project itself. > > > It's not that uncommon to have a program that's built as part of the > build needing to be run to support a later part of a build. For > example, there's a parser for the grammar definition for an > interpreter in one of our products. It's a C++ program. It gets > built, then run against the grammar definition file(s) for the > interpreter, and outputs some .cpp and .h files, which are then > compiled into things later in the build. > > You probably need to make at least some sort of way to define an > exception to that rule. Good point. -- James Harris
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-03-07 17:29 +0000 |
| Message-ID | <LjVnC.82747$kP6.19835@fx06.am4> |
| In reply to | #3874 |
On 07/03/2018 06:33, Robert Wessel wrote: > On Wed, 7 Mar 2018 04:54:59 +0000, James Harris > <james.harris.1@gmail.com> wrote: > >> On 05/03/2018 15:29, bartc wrote: >>> On 04/03/2018 08:43, James Harris wrote: >>>> On 03/03/2018 15:32, bartc wrote: >>> >>>>> These days I use a linker where /everything/ has to be specified >>>>> explicitly. >>>> >>>> Me too. Again, don't you think that much of that should be generatable >>>> by a program? >>> >>> There still needs to be some input to the program; where does that >>> exist, and in what format? >> >> Funny you should ask that. Assuming we are talking about the same thing >> I've been wrestling with that exact issue. And I think I am getting >> somewhere - as follows. >> >> The basic requirement is that the program which runs compilers and >> linkers (i.e. the replacement for make, which I'll call the 'compiler >> driver') knows exactly what command to run each time. For security, the >> programs it is allowed to invoke cannot not be part of the project as >> distributed but have to be specified locally. But there are also some >> settings which will need to be supplied with the project itself. > > > It's not that uncommon to have a program that's built as part of the > build needing to be run to support a later part of a build. For > example, there's a parser for the grammar definition for an > interpreter in one of our products. It's a C++ program. It gets > built, then run against the grammar definition file(s) for the > interpreter, and outputs some .cpp and .h files, which are then > compiled into things later in the build. > > You probably need to make at least some sort of way to define an > exception to that rule. With my stuff there are also circular dependencies that can be a problem. So, I have a program PC.EXE (an interpreter for language Q) written in a language M. The compiler for language M is written in Q. There are no external influences, except that the output of the M compiler is ASM source code. But I now use my own assembler, not compatible with others, and that is written in M. So how do you even start building this working purely from source code? For a project that uses C, it's easy to assume an existing C implementation. But here, there are no existing binaries that people might be expected to have. It's a bootstrapping problem. (For that reason, I've also made it possible for the M compiler to generate C source code. Then, if something happens and the compilers stop working, perhaps due to some bug in the binaries introduced several generations back but which has just manifested itself, then I can use the intermediate C source to fall back on. I can't fix it in the current sources as the compilers don't work. Actually the problem had been worse, as compiling PC requiring generating some include files using a script, like your example, but that script was in Q, and needed PC to run. And the versions of the new PC and the old PC were always out of kilter.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NoEmail@trraxvfeqa.prg> |
|---|---|
| Date | 2018-03-06 06:39 -0500 |
| Message-ID | <p7luil$2d5$1@gioia.aioe.org> |
| In reply to | #3851 |
On Thu, 1 Mar 2018 14:40:07 +0000 James Harris <james.harris.1@gmail.com> wrote: [c.l.c. dropped] > 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. Is it? ... I would not use the word "normal". Perhaps "common" or "typical"? AISI, it's just as likely to not be the case too, i.e., 50-50 or 60-40. > 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. What? ... E.g., from Linux stdio.h, where bits is a sub-directory of the include directory: #include <bits/sys_errlist.h> As most C compilers accept standard directory paths in the #include field, I would think you should be able to use '.' and '..' to refer to the current and up-directory. E.g., from Linux mp4ffint.h: #include "../../config.h" > 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? It shouldn't. When the compiler is allowed to decide where to look, it may look in the wrong place. The programmer should duplicate the includes or exports locally. While this requires more maintenance and could lead to coding mistakes, i.e., syncing issues, it ensures that the correct includes or exports are used, but if and only if, no mistakes are made. > 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. Are you trying to or trying not to generate the compile commands automatically? If it's a truly large project, there could be a dozen SS.h's spread all about the place. How do you intend to rectify finding the correct SS.h? There is no way you can do this automatically, unless the correct version of SS.h is placed in every directory where it is used, i.e., copied or linked to. > 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 Many files in a single directory doesn't scale well? ... (I'm quite not sure what to say to that. What is scaling here? file size? file quantity? It's not directories.) Obviously, you only need to copy or move the .o files together in a clean way to be linked, after traversing the sub-directories to compile the code. Isn't this what a makefile does? > especially what I do when one project needs to import files from > another. The first option is to use code duplication. It's much easier to just copy the code from one project into another, than it is to link to it, if licensing allows. Now, both projects separate and have what they need to compile. Alternately, create a library to link to. The library can be specified at compile time via compiler flags. I'm not sure how that helps with the #includes or search paths. Rod Pemberton -- feeback loop: Russian aggression -> World complains -> Russian paranioa -> Russian threats -> repeat
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2018-03-07 10:44 +0000 |
| Message-ID | <p7ofr0$jgu$1@dont-email.me> |
| In reply to | #3866 |
On 06/03/2018 11:39, Rod Pemberton wrote:
> On Thu, 1 Mar 2018 14:40:07 +0000
> James Harris <james.harris.1@gmail.com> wrote:
>
> [c.l.c. dropped]
>
>> 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.
>
> Is it? ...
>
> I would not use the word "normal". Perhaps "common" or "typical"?
>
> AISI, it's just as likely to not be the case too, i.e., 50-50 or 60-40.
>
>> 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.
>
> What? ...
>
> E.g., from Linux stdio.h, where bits is a sub-directory of the include
> directory:
>
> #include <bits/sys_errlist.h>
>
> As most C compilers accept standard directory paths in the #include
> field, I would think you should be able to use '.' and '..' to refer to
> the current and up-directory.
>
> E.g., from Linux mp4ffint.h:
>
> #include "../../config.h"
Yes, my mistake. I was thinking about languages which have a true
nested-namespace concept, but then expressed the issue in C for
familiarity. The issue remains the same, though, as to which folders the
compiler should look in for a subfolder called PP and a file within that
subfolder called SS.h.
>
>
>> 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?
>
> It shouldn't.
>
> When the compiler is allowed to decide where to look, it may look in
> the wrong place.
>
> The programmer should duplicate the includes or exports locally. While
> this requires more maintenance and could lead to coding mistakes, i.e.,
> syncing issues, it ensures that the correct includes or exports are
> used, but if and only if, no mistakes are made.
In theory each import or #include could specify the full path for
everything it was to include (assuming a language which supported such
specification) but that could be very inconvenient if the files were to
be copied elsewhere. A programmer might prefer relative references and
to get the compiler to search a list of folders for the name.
In what I have in mind it would be up to the programmer to specify what
to look for and where. In fact, since it would not be known in advance
where each project would be in the filesystem hierarchy then imports
would have to be relative to some start point or points.
Additionally, there might be some imports from other projects. They
could not be specified relative to the root of the project which does
the importing because they are not part of it. The folder in which the
compiler should search for such imports would have to be specified
separately, outside the project itself.
For example, I use a string formatter called sformat which behaves like
C's sprintf and which is useful in multiple projects. Rather than
duplicating it in each project, it's better for a C source file which
uses it to say
#include "sformat/sformat.h"
And that requires that the folder which contains the subfolder sformat
to be passed to the compiler in a -I {folder} form.
>
>> 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.
>
> Are you trying to or trying not to generate the compile commands
> automatically?
Trying to.
>
> If it's a truly large project, there could be a dozen SS.h's spread all
> about the place. How do you intend to rectify finding the correct
> SS.h? There is no way you can do this automatically, unless the
> correct version of SS.h is placed in every directory where it is used,
> i.e., copied or linked to.
It would have to be by use of a config file (or files) which told the
compiler driver where it had to tell the compiler to look. The query of
this thread is largely about how to specify such search paths and match
them to specific compiles.
>
>> 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
>
> Many files in a single directory doesn't scale well? ...
> (I'm quite not sure what to say to that. What is scaling here? file
> size? file quantity? It's not directories.)
Two things: number of files, and splitting the source into specific
sub-sources. Here's an example of the latter.
A project might start off having
PP/SS.c
PP/SS.h
But then it's determined that there should be different versions of SS
for different architectures. That part of the tree then becomes
PP/ibm_at/SS.nasm
PP/ibm_at/SS.h
PP/ibm_mca/SS.c
PP/ibm_mca/SS.h
PP/rpi_2/SS.c
PP/rpi_2/SS.h
Or, perhaps it becomes
PP/SS.h
PP/ibm_at/SS.nasm
PP/ibm_mca/SS.c
PP/rpi_2/SS.c
In either case, there are different source files for different machine
architectures. In the first, each has its own SS.h header. In the
second, the source files all use the same header, i.e. are written to
all export compatible symbols.
>
> Obviously, you only need to copy or move the .o files together in a
> clean way to be linked, after traversing the sub-directories to compile
> the code. Isn't this what a makefile does?
Sorry, I don't know what you mean about moving or copying the .o files
together. Can you say a bit more?
>
>> especially what I do when one project needs to import files from
>> another.
>
> The first option is to use code duplication. It's much easier to just
> copy the code from one project into another, than it is to link to it,
> if licensing allows. Now, both projects separate and have what they
> need to compile.
The problem with such copying is that it requires updates to the code to
also be propagated. Or, worse, some of the copies end up being forks and
then a programmer ends up with different versions of the same code and
begins to sow the seeds of a maintenance nightmare.
>
> Alternately, create a library to link to. The library can be specified
> at compile time via compiler flags. I'm not sure how that helps with
> the #includes or search paths.
Creating a library is a valid idea. But then its location has also to be
specified so I'm not sure it avoids the need to choose locations when
building code.
--
James Harris
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NoEmail@trraxvfeqa.prg> |
|---|---|
| Date | 2018-03-07 06:57 -0500 |
| Message-ID | <p7ok0g$ev3$1@gioia.aioe.org> |
| In reply to | #3876 |
On Wed, 7 Mar 2018 10:44:47 +0000
James Harris <james.harris.1@gmail.com> wrote:
> On 06/03/2018 11:39, Rod Pemberton wrote:
> > On Thu, 1 Mar 2018 14:40:07 +0000
> > James Harris <james.harris.1@gmail.com> wrote:
> >
> > [c.l.c. dropped]
> >> 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?
> >
> > It shouldn't.
> >
> > When the compiler is allowed to decide where to look, it may look in
> > the wrong place.
> >
> > The programmer should duplicate the includes or exports locally.
> > While this requires more maintenance and could lead to coding
> > mistakes, i.e., syncing issues, it ensures that the correct
> > includes or exports are used, but if and only if, no mistakes are
> > made.
>
> In theory each import or #include could specify the full path for
> everything it was to include (assuming a language which supported
> such specification) but that could be very inconvenient if the files
> were to be copied elsewhere.
Full path? ...
If it's something related to the system or compiler, then maybe a full
path, but the system or compiler should "know" where it's own
directories, includes, and libraries are located.
If it's related to the project, then I'd think you'd want a relative
path, as the person decompressing the archive could unpack it anywhere.
> A programmer might prefer relative
> references and to get the compiler to search a list of folders for
> the name.
Ok.
> In what I have in mind it would be up to the programmer to specify
> what to look for and where. In fact, since it would not be known in
> advance where each project would be in the filesystem hierarchy then
> imports would have to be relative to some start point or points.
What if the programmer specifies a directory that is off-limits?
e.g., privileged ... i.e., to prevent malfeasance
Wouldn't it be better to restrict the programmer to a few locations?
a) system libraries
b) compiler directories
c) sub-directories of the project
...
> Additionally, there might be some imports from other projects. They
> could not be specified relative to the root of the project which does
> the importing because they are not part of it. The folder in which
> the compiler should search for such imports would have to be
> specified separately, outside the project itself.
Should the programmer be able to do this? E.g., it's acceptable if the
programmer is working on their own machine with their own projects.
But, what if they're working on a multi-user machine. Should they be
allowed to access other people's projects? ...
> For example, I use a string formatter called sformat which behaves
> like C's sprintf and which is useful in multiple projects. Rather
> than duplicating it in each project, it's better for a C source file
> which uses it to say
>
> #include "sformat/sformat.h"
>
> And that requires that the folder which contains the subfolder
> sformat to be passed to the compiler in a -I {folder} form.
If the OS supports links, then you could have sformat.h as a link in
the current directory. Then, the include is simply:
#include "sfortmat.h"
Someone or something would need to set the link correctly, per project.
The only real issue AISI is that some OSes don't support links.
> >> 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
> >
> > Many files in a single directory doesn't scale well? ...
> > (I'm quite not sure what to say to that. What is scaling here? file
> > size? file quantity? It's not directories.)
>
> Two things: number of files, and splitting the source into specific
> sub-sources. Here's an example of the latter.
>
> A project might start off having
>
> PP/SS.c
> PP/SS.h
>
> But then it's determined that there should be different versions of
> SS for different architectures.
Whoa! Why? ...
If the language has something like C's preprocessor #ifdef's, then SS
can contain everything for all platforms. The #ifdef's select the
platform appropriate code.
> That part of the tree then becomes
>
> PP/ibm_at/SS.nasm
> PP/ibm_at/SS.h
>
> PP/ibm_mca/SS.c
> PP/ibm_mca/SS.h
>
> PP/rpi_2/SS.c
> PP/rpi_2/SS.h
>
Ok.
From the C perspective, you'd need a master include which includes the
appropriate sub-includes based on a defined macro:
PP/SS.h
/* SS.h start*/
#ifdef __IBMAT__
#include "ibm_at/SS.h"
#endif
#ifdef __IBMMCA__
#include "ibm_mca/SS.h"
#endif
#ifdef __RPI2__
#include "rpi_2/SS.h"
#endif
/* SS.h end */
Then, you'd use a compiler option e.g., -D to define __IBMAT__ or
__IBMMCA__ or __RPI2__ etc. Or, the #ifdef's could use platform
specific pre-defined macros. For most C compilers, there usually are
host specific defines.
E.g., "Pre-defined Compiler Macros"
https://sourceforge.net/p/predef/wiki/Compilers/
> Or, perhaps it becomes
>
> PP/SS.h
> PP/ibm_at/SS.nasm
> PP/ibm_mca/SS.c
> PP/rpi_2/SS.c
Ditto.
> In either case, there are different source files for different
> machine architectures. In the first, each has its own SS.h header. In
> the second, the source files all use the same header, i.e. are
> written to all export compatible symbols.
For C, #define's and #ifdef's take care of selecting code, including
#include lines.
I'm not sure what you're wanting for non-C situation.
> > Obviously, you only need to copy or move the .o files together in a
> > clean way to be linked, after traversing the sub-directories to
> > compile the code. Isn't this what a makefile does?
>
> Sorry, I don't know what you mean about moving or copying the .o
> files together. Can you say a bit more?
PP/one/one.c
PP/one/one.h
PP/one/one.o
PP/two/two.c
PP/two/two.h
PP/two/two.o
Say we need to link one.c and two.c after being compiled. We only need
to find one.o and two.o, and/or move/copy them to where we can link them
together. Make programs do that for Linux. For DOS, you might use
a .bat file to copy them into the same directory, since compilers can
usually link files together that are in the same directory from the
command line. Sometimes compilers can also accept paths on the command
line to the .o files. So, you wouldn't need anything in that regard,
except the complete command line with paths.
> >> especially what I do when one project needs to import files from
> >> another.
> >
> > The first option is to use code duplication. It's much easier to
> > just copy the code from one project into another, than it is to
> > link to it, if licensing allows. Now, both projects separate and
> > have what they need to compile.
>
s/projects separate/projects are separated/
> The problem with such copying is that it requires updates to the code
> to also be propagated.
There is code management software.
> Or, worse, some of the copies end up being forks
If they're all your projects, hopefully not. ;-)
If they're a mix of various people's project, yup ... But, they're
still separated, and each project will have what it needs, i.e., the
version that works with it. What if there is a radical rewrite of the
file from the master project? Now, you've got to completely recode your
project to continue using the master project's file. (Linux is a
nightmare like this. The most recent version of some project will
require the most recent version of two dozens other projects.)
> and then a programmer ends up with different versions of the
> same code and begins to sow the seeds of a maintenance nightmare.
That can't be any worse than having to rebuild dozens or more software
packages which are dependent upon each other, in order to update just
one package, as is the norm for Linux now.
Rod Pemberton
--
feeback loop: Russian aggression -> World complains -> Russian
paranioa -> Russian threats -> repeat
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2018-03-09 10:28 +0000 |
| Message-ID | <p7tnkf$gia$1@dont-email.me> |
| In reply to | #3877 |
On 07/03/2018 11:57, Rod Pemberton wrote:
> On Wed, 7 Mar 2018 10:44:47 +0000
> James Harris <james.harris.1@gmail.com> wrote:
>
>> On 06/03/2018 11:39, Rod Pemberton wrote:
>>> On Thu, 1 Mar 2018 14:40:07 +0000
>>> James Harris <james.harris.1@gmail.com> wrote:
>>>
>>> [c.l.c. dropped]
>
>>>> 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?
>>>
>>> It shouldn't.
>>>
>>> When the compiler is allowed to decide where to look, it may look in
>>> the wrong place.
>>>
>>> The programmer should duplicate the includes or exports locally.
>>> While this requires more maintenance and could lead to coding
>>> mistakes, i.e., syncing issues, it ensures that the correct
>>> includes or exports are used, but if and only if, no mistakes are
>>> made.
>>
>> In theory each import or #include could specify the full path for
>> everything it was to include (assuming a language which supported
>> such specification) but that could be very inconvenient if the files
>> were to be copied elsewhere.
>
> Full path? ...
>
> If it's something related to the system or compiler, then maybe a full
> path, but the system or compiler should "know" where it's own
> directories, includes, and libraries are located.
>
> If it's related to the project, then I'd think you'd want a relative
> path, as the person decompressing the archive could unpack it anywhere.
>
>> A programmer might prefer relative
>> references and to get the compiler to search a list of folders for
>> the name.
>
> Ok.
>
>> In what I have in mind it would be up to the programmer to specify
>> what to look for and where. In fact, since it would not be known in
>> advance where each project would be in the filesystem hierarchy then
>> imports would have to be relative to some start point or points.
>
> What if the programmer specifies a directory that is off-limits?
> e.g., privileged ... i.e., to prevent malfeasance
>
> Wouldn't it be better to restrict the programmer to a few locations?
> a) system libraries
> b) compiler directories
> c) sub-directories of the project
> ...
Possibly, yes. What I'd prefer is to have a universal naming system.
(You may remember I've asked about that before.) The idea would be that
universal names are used in config files (and source files on languages
which support them). Then a cache is maintained on the local machine of
the named files, and all builds are run against the local copies.
>
>> Additionally, there might be some imports from other projects. They
>> could not be specified relative to the root of the project which does
>> the importing because they are not part of it. The folder in which
>> the compiler should search for such imports would have to be
>> specified separately, outside the project itself.
>
> Should the programmer be able to do this? E.g., it's acceptable if the
> programmer is working on their own machine with their own projects.
> But, what if they're working on a multi-user machine. Should they be
> allowed to access other people's projects? ...
As above, IMO it would be good for names to be universal; if another
programmer had published a certain project (i.e. made it available under
the universal name) then we could refer to it in our project just by
using its name.
Other than that, I would think an individual programmer could have
multiple projects and choose to cross-refer between them as needed.
>
>> For example, I use a string formatter called sformat which behaves
>> like C's sprintf and which is useful in multiple projects. Rather
>> than duplicating it in each project, it's better for a C source file
>> which uses it to say
>>
>> #include "sformat/sformat.h"
>>
>> And that requires that the folder which contains the subfolder
>> sformat to be passed to the compiler in a -I {folder} form.
>
> If the OS supports links, then you could have sformat.h as a link in
> the current directory. Then, the include is simply:
>
> #include "sfortmat.h"
>
> Someone or something would need to set the link correctly, per project.
>
> The only real issue AISI is that some OSes don't support links.
Agreed. That's what I tend to do at present on Unix.
>
>>>> 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
>>>
>>> Many files in a single directory doesn't scale well? ...
>>> (I'm quite not sure what to say to that. What is scaling here? file
>>> size? file quantity? It's not directories.)
>>
>> Two things: number of files, and splitting the source into specific
>> sub-sources. Here's an example of the latter.
>>
>> A project might start off having
>>
>> PP/SS.c
>> PP/SS.h
>>
>> But then it's determined that there should be different versions of
>> SS for different architectures.
>
> Whoa! Why? ...
A good example which you will readily understand is an OS's first-level
interrupt handler. Each target architecture would be very different from
that of another so would need different source code.
>
> If the language has something like C's preprocessor #ifdef's, then SS
> can contain everything for all platforms. The #ifdef's select the
> platform appropriate code.
Not if different people provide the code for different architectures!
>
>> That part of the tree then becomes
>>
>> PP/ibm_at/SS.nasm
>> PP/ibm_at/SS.h
>>
>> PP/ibm_mca/SS.c
>> PP/ibm_mca/SS.h
>>
>> PP/rpi_2/SS.c
>> PP/rpi_2/SS.h
>>
>
> Ok.
>
> From the C perspective, you'd need a master include which includes the
> appropriate sub-includes based on a defined macro:
>
> PP/SS.h
>
> /* SS.h start*/
> #ifdef __IBMAT__
> #include "ibm_at/SS.h"
> #endif
> #ifdef __IBMMCA__
> #include "ibm_mca/SS.h"
> #endif
> #ifdef __RPI2__
> #include "rpi_2/SS.h"
> #endif
> /* SS.h end */
>
> Then, you'd use a compiler option e.g., -D to define __IBMAT__ or
> __IBMMCA__ or __RPI2__ etc. Or, the #ifdef's could use platform
> specific pre-defined macros. For most C compilers, there usually are
> host specific defines.
>
> E.g., "Pre-defined Compiler Macros"
> https://sourceforge.net/p/predef/wiki/Compilers/
Yes, although that wouldn't work if the different modules came from
different sources or were written in different languages.
>
>> Or, perhaps it becomes
>>
>> PP/SS.h
>> PP/ibm_at/SS.nasm
>> PP/ibm_mca/SS.c
>> PP/rpi_2/SS.c
>
> Ditto.
>
>> In either case, there are different source files for different
>> machine architectures. In the first, each has its own SS.h header. In
>> the second, the source files all use the same header, i.e. are
>> written to all export compatible symbols.
>
> For C, #define's and #ifdef's take care of selecting code, including
> #include lines.
>
> I'm not sure what you're wanting for non-C situation.
>
>>> Obviously, you only need to copy or move the .o files together in a
>>> clean way to be linked, after traversing the sub-directories to
>>> compile the code. Isn't this what a makefile does?
>>
>> Sorry, I don't know what you mean about moving or copying the .o
>> files together. Can you say a bit more?
>
> PP/one/one.c
> PP/one/one.h
> PP/one/one.o
> PP/two/two.c
> PP/two/two.h
> PP/two/two.o
>
> Say we need to link one.c and two.c after being compiled. We only need
> to find one.o and two.o, and/or move/copy them to where we can link them
> together. Make programs do that for Linux. For DOS, you might use
> a .bat file to copy them into the same directory, since compilers can
> usually link files together that are in the same directory from the
> command line. Sometimes compilers can also accept paths on the command
> line to the .o files. So, you wouldn't need anything in that regard,
> except the complete command line with paths.
One could specify the .o files on the linker command line even if they
were in different places, AIUI, so I am not sure that copying them would
be necessary. It might be a good idea, though, as long as it did not
lead to name conflicts.
>
>>>> especially what I do when one project needs to import files from
>>>> another.
>>>
>>> The first option is to use code duplication. It's much easier to
>>> just copy the code from one project into another, than it is to
>>> link to it, if licensing allows. Now, both projects separate and
>>> have what they need to compile.
>>
>
> s/projects separate/projects are separated/
>
>> The problem with such copying is that it requires updates to the code
>> to also be propagated.
>
> There is code management software.
>
>> Or, worse, some of the copies end up being forks
>
> If they're all your projects, hopefully not. ;-)
:-) I've seen it in a work environment: a programmer copying an existing
module and tweaking it to get a job done, rather than modifying the
original to cope with the new requirement. Unfortunately, that leads to
one program (the new one) including meaningless code, and an extra
maintenance burden - two programs to change instead of one as common
requirements change.
>
> If they're a mix of various people's project, yup ... But, they're
> still separated, and each project will have what it needs, i.e., the
> version that works with it. What if there is a radical rewrite of the
> file from the master project? Now, you've got to completely recode your
> project to continue using the master project's file. (Linux is a
> nightmare like this. The most recent version of some project will
> require the most recent version of two dozens other projects.)
As long as the interfaces stay the same or are backward compatible then
there should be no need to rewrite programs which work through those
interfaces.
>
>> and then a programmer ends up with different versions of the
>> same code and begins to sow the seeds of a maintenance nightmare.
>
> That can't be any worse than having to rebuild dozens or more software
> packages which are dependent upon each other, in order to update just
> one package, as is the norm for Linux now.
I don't recognise the problem you are referring to. IME Unix package
managers handle all that for you. And if you mean source code, if you
update X.h then it would be normal to update all object files for all C
sources which depend on X.h - i.e. import it directly or indirectly.
--
James Harris
[toc] | [prev] | [next] | [standalone]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | comp.lang.misc
csiph-web