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 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | Rod Pemberton <NoEmail@trraxvfeqa.prg> |
|---|---|
| Date | 2018-03-11 07:44 -0400 |
| Message-ID | <p8388p$bn8$2@gioia.aioe.org> |
| In reply to | #3886 |
On Fri, 9 Mar 2018 10:28:26 +0000 James Harris <james.harris.1@gmail.com> wrote: > Yes, although that wouldn't work if the different modules came from > different sources or were written in different languages. A new wrinkle is added ... What I just "heard" was: a) decentralized (no central project maintainer) b) independent (of any existing programming language) As for a), if there is no hierarchical file structure for a master include file, and there is also no central project maintainer, how does a project contributor or each new module tell the build script that it needs to build that part of the project? sentinel? magic file? execute a special program? As for b), can't existing preprocessors, e.g., for C, or existing build tool chains, such as make or cmake, do the job? I.e., what is requiring something new to be created? Rod Pemberton -- feedback loop: Russian aggression -> World complains -> Russian paranoia -> Russian threats -> repeat
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2018-03-12 22:44 +0000 |
| Message-ID | <p86vs7$iq$1@dont-email.me> |
| In reply to | #3890 |
On 11/03/2018 11:44, Rod Pemberton wrote:
> On Fri, 9 Mar 2018 10:28:26 +0000
> James Harris <james.harris.1@gmail.com> wrote:
>
>
>> Yes, although that wouldn't work if the different modules came from
>> different sources or were written in different languages.
>
> A new wrinkle is added ...
>
> What I just "heard" was:
>
> a) decentralized (no central project maintainer)
> b) independent (of any existing programming language)
>
> As for a), if there is no hierarchical file structure for a master
> include file, and there is also no central project maintainer, how does
> a project contributor or each new module tell the build script that it
> needs to build that part of the project? sentinel? magic file? execute
> a special program?
There wouldn't need to be an explicit notification. The idea is that the
build script would detect what needed to be built or rebuilt.
>
> As for b), can't existing preprocessors, e.g., for C, or existing
> build tool chains, such as make or cmake, do the job? I.e., what is
> requiring something new to be created?
Here are some problems I've noted with make.
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. Unfortunately, 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.
5. At some point I want to link program hierarchies with the universal
naming system we've discussed before, and get files from the internet,
using the local file system to cache them. The make program won't do any
of that.
6. Automatic configuration is very limited under make.
This has come to a head now because I have reached a point with other
things where I want multiple object files to be built from each source
file, and need greater automaticity - i.e. where the build script works
out which compilers to use, which 'include folders' to specify to the
compiler, which object modules to link together when invoking the
linker, and so on.
--
James Harris
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NoEmail@trraxvfeqa.prg> |
|---|---|
| Date | 2018-03-14 01:47 -0400 |
| Message-ID | <p8act5$aj4$2@gioia.aioe.org> |
| In reply to | #3892 |
On Mon, 12 Mar 2018 22:44:22 +0000 James Harris <james.harris.1@gmail.com> wrote: <snip> > 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. I happen to like DOS .bat files, but these are a) for DOS only, b) for simpler projects. > 4. Unfortunately, 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. I think that's true of any executable in a privileged environment. AFAIK, your only option, if this is a concern, is to build in a non-privileged account, at least for Unix or Linux etc. VMS had ACLs. IIRC, SysV had the ability to set per user privileges for executables. I don't recall what Stratus Continuum's did here for security ... > 5. At some point I want to link program hierarchies with the > universal naming system we've discussed before, and get files from > the internet, using the local file system to cache them. The make > program won't do any of that. Uh ... > 6. Automatic configuration is very limited under make. > > This has come to a head now because I have reached a point with other > things where I want multiple object files to be built from each > source file, and need greater automaticity - i.e. where the build > script works out which compilers to use, which 'include folders' to > specify to the compiler, which object modules to link together when > invoking the linker, and so on. Multiple object files? Cross-compiling for multiple targets? Rod Pemberton -- feedback loop: Russian aggression -> World complains -> Russian paranoia -> Russian threats -> repeat
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-03-14 10:23 +0000 |
| Message-ID | <9K6qC.684$hq2.22@fx42.am4> |
| In reply to | #3894 |
On 14/03/2018 05:47, Rod Pemberton wrote: > On Mon, 12 Mar 2018 22:44:22 +0000 > James Harris <james.harris.1@gmail.com> wrote: > > <snip> > >> 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. > > I happen to like DOS .bat files, but these are a) for DOS only, b) for > simpler projects. Once you've established which programs to run and on what files and with which options, then a linear script like a .bat file containing DOS commands will do as well as any other. Or you print it out and just enter the commands by hand. (You only need to work out how error handling is done; if it's just an abort then that's simple. If it means changing script then it's harder.) When you need some programming in order to figure that sequence of actions, what you don't want is to have to do it in some crazy syntax that either you have to write, or to try and decipher some one else's. What's wrong with using any general purpose language that uses universal constructs that everyone will know? Why does it have to be such a mystery? (I don't use makefiles because I don't think any of my C compilers have a working version. Or if they do, it invariably reports some error or other a few lines into the makefile, and I won't have a clue how to fix it. While my other languages don't have such a concept.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2018-03-14 11:30 +0100 |
| Message-ID | <m23713rlss.fsf@despina.home> |
| In reply to | #3895 |
bartc <bc@freeuk.com> writes:
> On 14/03/2018 05:47, Rod Pemberton wrote:
>> On Mon, 12 Mar 2018 22:44:22 +0000
>> James Harris <james.harris.1@gmail.com> wrote:
>>
>> <snip>
>>
>>> 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.
>>
>> I happen to like DOS .bat files, but these are a) for DOS only, b) for
>> simpler projects.
>
> Once you've established which programs to run and on what files and
> with which options, then a linear script like a .bat file containing
> DOS commands will do as well as any other. Or you print it out and
> just enter the commands by hand.
>
> (You only need to work out how error handling is done; if it's just an
> abort then that's simple. If it means changing script then it's
> harder.)
>
> When you need some programming in order to figure that sequence of
> actions, what you don't want is to have to do it in some crazy syntax
> that either you have to write, or to try and decipher some one else's.
>
> What's wrong with using any general purpose language that uses
> universal constructs that everyone will know? Why does it have to be
> such a mystery?
>
> (I don't use makefiles because I don't think any of my C compilers
> have a working version. Or if they do, it invariably reports some
> error or other a few lines into the makefile, and I won't have a clue
> how to fix it. While my other languages don't have such a concept.)
You don't know what make and makefiles are. It's not a "C concept"!
makefiles are just scripts (bash or sh or other, depending on the SHELL
variable), but structured into chunks executed to transform some input
files into output files. Those dependencies rules are written:
outputfile… : inputfile…
shell command…
The problem with writing scripts (be it bat or sh or other) to build
systems, is that they're not efficient for iterative development, when
you modify only one or a few source files. The scripts will recompile
everything from the start, which may take several minutes or even hours.
By declaring the dependencies between inputs and outputs, with commands
to perform the transformation, make is able to avoid useless work, by
executing only the commands strictly needed to update the target after
the sources are modified.
So basically, if you can write a script, you can write a makefile.
There's no secret to it.
--
__Pascal J. Bourguignon
http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-03-14 11:30 +0000 |
| Message-ID | <rJ7qC.304$rA1.23@fx34.am4> |
| In reply to | #3896 |
On 14/03/2018 10:30, Pascal J. Bourguignon wrote: > bartc <bc@freeuk.com> writes: >> (I don't use makefiles because I don't think any of my C compilers >> have a working version. Or if they do, it invariably reports some >> error or other a few lines into the makefile, and I won't have a clue >> how to fix it. While my other languages don't have such a concept.) > > You don't know what make and makefiles are. It's not a "C concept"! So, where does the program to run the makefile come from? On Windows, I've only seem them associated with C compilers, if they even have one. > makefiles are just scripts (bash or sh or other, depending on the SHELL > variable), but structured into chunks executed to transform some input > files into output files. Those dependencies rules are written: > > > outputfile… : inputfile… > shell command… > > > The problem with writing scripts (be it bat or sh or other) to build > systems, is that they're not efficient for iterative development, when > you modify only one or a few source files. The scripts will recompile > everything from the start, which may take several minutes or even hours. I've seen makefiles used for the most trivial of projects. And actually, a lot of the time you have an extra level of script (a 'configure' file) to generate the makefile! Outside of Unix, such scripts won't work, the makefiles tend to assume specific compilers, and even the compilers may fail to run the makefile. (See CPython project on Github; they have an 18Kloc configure file, and 1.7Kloc 'makefile.pre.in' I guess other makefiles are generated as it goes. For all that, it is generally acknowledged this doesn't work on Windows, and they provide instead a solution that relies on MSVC and Visual studio. And Git. And SVN. And MSBUILD. And then it still didn't work when I followed the instructions to the letter. CPython isn't that big a program, so what is the problem?) > By declaring the dependencies between inputs and outputs, with commands > to perform the transformation, make is able to avoid useless work, by > executing only the commands strictly needed to update the target after > the sources are modified. Is it necessary to invent a whole new language just for that purpose? A project is already written in some language A and you are reasonably enough expected to have a tool that can compile A. With a makefile, the project now effectively is written in language B as well, and you need a compatible tool that will run B. (I understand makefiles vary in syntax across different compilers for A, so that a makefile that works for any implementation of A is harder.) With configure scripts, the project is effectively written in yet a third language! Some use M4 as well as Bash. If there are any special requirements, then just specify them in English (as well as a makefile, if you have to supply one). Programmers are quite capable of knocking up their own script if they have to, using a language that they know intimately, is available, that they already know works, and that they can debug and maintain. > you modify only one or a few source files. The scripts will recompile > everything from the start, which may take several minutes or even hours. This is a separate problem that needs to be investigated. Why are they taking minutes and hours? Is it due to executing all those layers of scripts and those thousands of lines of shell commands? Are the compilers just too slow? What total number of sourcelines are involved, and what is the net throughput in lines per second? Are there just too many files involved? [I understand MS' VS used 1.5M files; a 'fast' build was 11 hours; a normal one, 60 hours. Here's a simple idea: just write smaller programs!] It might be a project management problem more than anything else. But using incremental builds to hide any inefficiencies may allow such problems to build up, at a further cost of extra layers of scripting. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2018-03-14 13:30 +0100 |
| Message-ID | <m2y3iurg9s.fsf@despina.home> |
| In reply to | #3899 |
bartc <bc@freeuk.com> writes: > On 14/03/2018 10:30, Pascal J. Bourguignon wrote: >> bartc <bc@freeuk.com> writes: > >>> (I don't use makefiles because I don't think any of my C compilers >>> have a working version. Or if they do, it invariably reports some >>> error or other a few lines into the makefile, and I won't have a clue >>> how to fix it. While my other languages don't have such a concept.) >> >> You don't know what make and makefiles are. It's not a "C concept"! > > So, where does the program to run the makefile come from? > > On Windows, I've only seem them associated with C compilers, if they > even have one. GNU make is a stand alone program. >> makefiles are just scripts (bash or sh or other, depending on the SHELL >> variable), but structured into chunks executed to transform some input >> files into output files. Those dependencies rules are written: >> >> >> outputfile… : inputfile… >> shell command… >> >> >> The problem with writing scripts (be it bat or sh or other) to build >> systems, is that they're not efficient for iterative development, when >> you modify only one or a few source files. The scripts will recompile >> everything from the start, which may take several minutes or even hours. > > I've seen makefiles used for the most trivial of projects. And > actually, a lot of the time you have an extra level of script (a > 'configure' file) to generate the makefile! Yes, they didn't understand make either. Look at the makefile of kermit instead. > Outside of Unix, such scripts won't work, the makefiles tend to assume > specific compilers, and even the compilers may fail to run the > makefile. Compilers don't run makefiles. It's the make program that interprets the makefile. Of course, the scripts you write in your makefile should be POSIX scripts if you want them to be portable. (And who is foolish enough to use MS-Windows in the 3rd millenum!?) >> By declaring the dependencies between inputs and outputs, with commands >> to perform the transformation, make is able to avoid useless work, by >> executing only the commands strictly needed to update the target after >> the sources are modified. > > Is it necessary to invent a whole new language just for that purpose? Indeed it is not. And this is why make is so simple: no new language is invented. On the other hand, maven, scons, rake, etc, are all new languages to implement the same feature. > A project is already written in some language A and you are reasonably > enough expected to have a tool that can compile A. You have a bootstrapping problem: how do you know how to build the tool that will build your system? For example, in Common Lisp nowadays we usually use asdf to build systems. The asdf system itself cannot be built with asdf! It needs to be distributed as a single file to be loaded before you can use it to build the other systems. On the other hand, using a makefile, and a batch Common Lisp compiler, you can build your lisp projects without any bootstrapping problem. > With a makefile, the project now effectively is written in language B > as well, and you need a compatible tool that will run B. (I understand > makefiles vary in syntax across different compilers for A, so that a > makefile that works for any implementation of A is harder.) No, you are crazy. make doesn't know anything about compilers, makefiles are just plain scripts as I explained. Do your bash scripts use different syntax for different compilers? This would be mind-boggling. What mess do you have in your brains to think such a thing? > With configure scripts, the project is effectively written in yet a > third language! Some use M4 as well as Bash. I would rather just ignore configure scripts. Let's assume they indeed solve some problem and let's bear them when they're provided, but I would never generate one (yes, because you don't write your own configure script, there's actually at least another meta-level where you write a specification for your configuration need, and a tool is used to generate them!) >> you modify only one or a few source files. The scripts will recompile >> everything from the start, which may take several minutes or even hours. > > This is a separate problem that needs to be investigated. Why are they > taking minutes and hours? Is it due to executing all those layers of > scripts and those thousands of lines of shell commands? Often, just because it's the time that is required. Not all programs are small. > Are the compilers just too slow? What total number of sourcelines are > involved, and what is the net throughput in lines per second? Are > there just too many files involved? But indeed, often compilation time depends on the complexity of the programming language, and choosing another programming language can lead to faster compilation times. How often can you change the programming language of a project just for that reason? Even before starting the project? > It might be a project management problem more than anything else. But > using incremental builds to hide any inefficiencies may allow such > problems to build up, at a further cost of extra layers of scripting. You're not serious. Again, not all projects are small programs you can compile with Turbo-Pascal. -- __Pascal J. Bourguignon http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-03-14 14:32 +0000 |
| Message-ID | <foaqC.14911$8G7.12649@fx36.am4> |
| In reply to | #3900 |
On 14/03/2018 12:30, Pascal J. Bourguignon wrote: > bartc <bc@freeuk.com> writes: >> On Windows, I've only seem them associated with C compilers, if they >> even have one. > > GNU make is a stand alone program. So why does every C compiler I've seen come with its own version of 'make'? >> Outside of Unix, such scripts won't work, the makefiles tend to assume >> specific compilers, and even the compilers may fail to run the >> makefile. > > Compilers don't run makefiles. It's the make program that interprets > the makefile. I write my own compilers. Specifically, I've written my own C compiler. I don't have a make program. The last thing I want when trying it out on a sample open source project, ostensibly written in C, is being unable to compile it because the necessary build information - what file goes where - is hidden away inside make files and configure scripts, which I can rarely make work. See example below. > Of course, the scripts you write in your makefile should be POSIX > scripts if you want them to be portable. > > (And who is foolish enough to use MS-Windows in the 3rd millenum!?) The stuff I do I try to keep independent of the OS so it should be irrelevant. Unix applications' source code seem to be a big mountain of interdependencies on dozens of utilities, so it's not surprising they transfer badly to Windows. But you can't blame Windows for not having a big pile of dependencies of its own that corresponds exactly to the Unix one. > Indeed it is not. And this is why make is so simple: no new language is > invented. No matter how 'simple' you think it is, it is still a language, one that is incompatible with any other, and one that needs a special interpreter to be able to use. >> A project is already written in some language A and you are reasonably >> enough expected to have a tool that can compile A. > > You have a bootstrapping problem: how do you know how to build the tool > that will build your system? How do you build 'make'? > For example, in Common Lisp nowadays we usually use asdf to build > systems. The asdf system itself cannot be built with asdf! It needs to > be distributed as a single file to be loaded before you can use it to > build the other systems. > > On the other hand, using a makefile, and a batch Common Lisp compiler, > you can build your lisp projects without any bootstrapping problem. I don't know what a 'batch CL compiler' is. But bootstrapping is anyway a separate subject, and what that doesn't really apply here. (A few years ago, I decided to make some of my programs, written in my languages, available to others to compile from source. But I chose to generate C source files, and each program was a single source file. The only requirement was a C compiler. No make or bash or anything else. And C was chosen because compilers for it are ubiquitous.) >> With a makefile, the project now effectively is written in language B >> as well, and you need a compatible tool that will run B. (I understand >> makefiles vary in syntax across different compilers for A, so that a >> makefile that works for any implementation of A is harder.) > > No, you are crazy. make doesn't know anything about compilers, > makefiles are just plain scripts as I explained. Do your bash scripts > use different syntax for different compilers? This would be > mind-boggling. What mess do you have in your brains to think such a thing? OK, let's try it out. I've just downloaded the open source Tiny C project. I try 'make' from various compilers with the following results: MSVC's nmake: makefile(7) : fatal error U1034: syntax error : separator missing Pelles C's pomake: A screen or two of warnings scroll up the screen. Then it crashes. lccwin's make: No targets provided near line 6 gcc's make (a make.exe which is inside the bin directly of my gcc/tdm installation): "The program can't start because linintl-8.dll is missing from your computer" Tiny C: [It doesn't appear to come with 'make'.] This is completely typical of my experience with make files. (This makefile is here: https://pastebin.com/raw/Qz8QAiuS. It certainly looks like a language to me.) > I would rather just ignore configure scripts. Let's assume they indeed > solve some problem and let's bear them when they're provided, You can't ignore the ones that come with other projects, because there will be some 1-line config.h file that they end up generating that is essential to be able to build. >> Are the compilers just too slow? What total number of sourcelines are >> involved, and what is the net throughput in lines per second? Are >> there just too many files involved? > > But indeed, often compilation time depends on the complexity of the > programming language, and choosing another programming language can lead > to faster compilation times. But what figures are we talking about? Are they reasonable or unreasonable for the amount of work involved? Such analyses don't get done probably because the people it affects aren't the ones who can do anything about it. > You're not serious. Again, not all projects are small programs you can > compile with Turbo-Pascal. I would never tolerate any system where you had to wait even a minute for each build. There are plenty of things I've done in the past for avoiding any sort of delay when rebuilding any project. That meant a virtually zero-delay turnaround most of the time. This included working on very slow 8- and 16-bit systems with limited memory and storage. And stuff I'm doing now involves creating some very fast compilers: two compilers peaking at between 0.5M and 1M lines per second, and an assembler peaking at 4M lines per second. On one compiler I overhauled recently, all modules of the whole compiler were recompiled from scratch each time I ran it; it took 0.03 seconds [24Kloc in 20-odd modules], so I didn't notice. Pressing a key on my keyboard takes far longer. Anyway, there are lots of things that can be done, but I admit it is more difficult if dependencies on many cumbersome tools have been developed, or it is not possible to resist just making programs unnecessarily huge. (I remember downloading an implementation - already built - of GHC (Haskell). It was a 2GB download, including a bundled 300MB version of the gcc C compiler. It didn't work. But even if it did, 2GB, really? I had some 20-line test programs I wanted to try out, not run the Space Shuttle. (Which, incidentally, managed with much smaller programs!) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2018-03-14 16:01 +0100 |
| Message-ID | <m2h8pir9a7.fsf@despina.home> |
| In reply to | #3903 |
bartc <bc@freeuk.com> writes: > On 14/03/2018 12:30, Pascal J. Bourguignon wrote: >> bartc <bc@freeuk.com> writes: > > >>> On Windows, I've only seem them associated with C compilers, if they >>> even have one. >> >> GNU make is a stand alone program. > > So why does every C compiler I've seen come with its own version of 'make'? You're living in a fantasy-land. GNU gcc is not delivered with any make. clang is not delivered with any make. >>> Outside of Unix, such scripts won't work, the makefiles tend to assume >>> specific compilers, and even the compilers may fail to run the >>> makefile. >> >> Compilers don't run makefiles. It's the make program that interprets >> the makefile. > > I write my own compilers. Specifically, I've written my own C > compiler. I don't have a make program. No reason to have or provide any. Let your users use whatever system builing software they want. > The last thing I want when trying it out on a sample open source > project, ostensibly written in C, is being unable to compile it > because the necessary build information - what file goes where - is > hidden away inside make files and configure scripts, which I can > rarely make work. See example below. make is a POSIX standard tool! http://pubs.opengroup.org/onlinepubs/007904975/utilities/make.html You can assume it is present on the system, so you can provide POSIX makefiles and be confident that the users will be able to compile your programs. >> Of course, the scripts you write in your makefile should be POSIX >> scripts if you want them to be portable. >> >> (And who is foolish enough to use MS-Windows in the 3rd millenum!?) > > The stuff I do I try to keep independent of the OS so it should be > irrelevant. Unix applications' source code seem to be a big mountain > of interdependencies on dozens of utilities, so it's not surprising > they transfer badly to Windows. > > But you can't blame Windows for not having a big pile of dependencies > of its own that corresponds exactly to the Unix one. No, but I can blame you for using MS-Windows! DUH! Don't! I mean the reason why you shouldn't use MS-Windows is because it's a poor POSIX platform. >> Indeed it is not. And this is why make is so simple: no new language is >> invented. > > No matter how 'simple' you think it is, it is still a language, one > that is incompatible with any other, and one that needs a special > interpreter to be able to use. It's a standard tool. >>> A project is already written in some language A and you are reasonably >>> enough expected to have a tool that can compile A. >> >> You have a bootstrapping problem: how do you know how to build the tool >> that will build your system? > > How do you build 'make'? You use the previous version of make and a C compiler. How do you build your C compiler? >>> With a makefile, the project now effectively is written in language B >>> as well, and you need a compatible tool that will run B. (I understand >>> makefiles vary in syntax across different compilers for A, so that a >>> makefile that works for any implementation of A is harder.) >> >> No, you are crazy. make doesn't know anything about compilers, >> makefiles are just plain scripts as I explained. Do your bash scripts >> use different syntax for different compilers? This would be >> mind-boggling. What mess do you have in your brains to think such a thing? > > OK, let's try it out. I've just downloaded the open source Tiny C > project. I try 'make' from various compilers with the following > results: > > MSVC's nmake: > > makefile(7) : fatal error U1034: syntax error : separator missing > > Pelles C's pomake: > > A screen or two of warnings scroll up the screen. Then it crashes. > > lccwin's make: > > No targets provided near line 6 > > gcc's make (a make.exe which is inside the bin directly of my gcc/tdm > installation): > > "The program can't start because linintl-8.dll is missing from your > computer" > > Tiny C: > > [It doesn't appear to come with 'make'.] > > > This is completely typical of my experience with make files. (This > makefile is here: https://pastebin.com/raw/Qz8QAiuS. It certainly > looks like a language to me.) Use a unix system! You have so many choices: linux, freebsd, openbsd, darwin, illumos, etc. >>> Are the compilers just too slow? What total number of sourcelines are >>> involved, and what is the net throughput in lines per second? Are >>> there just too many files involved? >> >> But indeed, often compilation time depends on the complexity of the >> programming language, and choosing another programming language can lead >> to faster compilation times. > > But what figures are we talking about? Are they reasonable or > unreasonable for the amount of work involved? Such analyses don't get > done probably because the people it affects aren't the ones who can do > anything about it. I've compiled linux on an old Pentium laptop (13 hours), and on a new Athlon system (5 minutes). (written in C). The last professional project I worked on, compiling all the software (multiple SDK and applications and tests, for various targets), took about half an hour per target on the CI (we systematically compiled everything from scratch in that configuration, since we basically check out a new version each time). (written in C, with some C++). But to run tests locally when developping it would be out of question to wait half an hour recompiling everything. The build system must take the shortcut of recompiling only what has been changed, so that you can compile-and-debug instantaneously. Long compilation times are also influenced by the language; for example, if you use a lot of templates in C++ programs, this will take more compilation time (templates are executed at compilation time!). Also, since C++ needs a lot of thing in the class definition in the header files, the dependencies are very bad, and making small changes often require recompiling many more files than when using other programming languages. > It didn't work. But even if it did, 2GB, really? I had some 20-line > test programs I wanted to try out, not run the Space Shuttle. (Which, > incidentally, managed with much smaller programs!) But then again, the compilers are pre-installed. I mean, you should have already installed them a long time ago on your system! For most of them it's trivial and easy, since the distributions provide packages for almost all of them. apt-get install ghc works nicely and effortlessly on a lot of linux system. Similar package installation commands are avaialble on all the other unix systems (practical POSIX systems). Therefore trying out 20-liners is no problem. Now of course, if you use a system that comes with a Solitaire pre-installed… your choice. -- __Pascal J. Bourguignon http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-03-14 19:28 +0000 |
| Message-ID | <AJeqC.8794$0g.3067@fx06.am4> |
| In reply to | #3904 |
On 14/03/2018 15:01, Pascal J. Bourguignon wrote: > bartc <bc@freeuk.com> writes: > >> On 14/03/2018 12:30, Pascal J. Bourguignon wrote: >>> bartc <bc@freeuk.com> writes: >> >> >>>> On Windows, I've only seem them associated with C compilers, if they >>>> even have one. >>> >>> GNU make is a stand alone program. >> >> So why does every C compiler I've seen come with its own version of 'make'? > > You're living in a fantasy-land. > GNU gcc is not delivered with any make. > clang is not delivered with any make. This is part of what makes C, gnu, gcc and everything else that comes from Unix, Linux whatever so confusing. And exasperating. Is something part of the OS, is it part of C, or part of the compiler? Is is standard C, or a gnu C? I remember downloading gcc for windows (called mingw), and complaining that it had some major part missing: standard headers, or a linker or something. Apparently, that wasn't a problem at all; after all I downloaded a /compiler/, a compiler is what I got, and a compiler doesn't include anything else. Meanwhile, every other C compiler for Windows is self-contained with everything needed to turn .c files to .exe files (except perhaps a reliable way to run make). But what gets me is that very strange attitude that comes with any program originating from *nix. > make is a POSIX standard tool! > http://pubs.opengroup.org/onlinepubs/007904975/utilities/make.html > You can assume it is present on the system, so you can provide POSIX > makefiles and be confident that the users will be able to compile your > programs. What does that mean? If I type 'make' on Windows, it usually says 'file not found'. > No, but I can blame you for using MS-Windows! DUH! Don't! > I mean the reason why you shouldn't use MS-Windows is because it's a > poor POSIX platform. What's POSIX got to do with anything with anything being discussed? But clearly, it sounds like something that originated in Unix, that might have a been good fit for how Unix works, but a poor one for Windows. As it happens, I didn't choose Windows, my customers did, because it in the early 90s is was very easy to buy Windows machines off the shelf, completing with fully working peripherals, and much harder with Unix machines. And also easier to run additional software, not just mine. Or to anything really because everyone had them. But I don't remember having any build problems under Windows that necessitated my requiring the use of makefiles or make utilities. >> No matter how 'simple' you think it is, it is still a language, one >> that is incompatible with any other, and one that needs a special >> interpreter to be able to use. > > It's a standard tool. It's one that I've never used nor needed. And I was always creating applications up to, and beyond, the capacities of the machine I was developing for, so it's not like they were too small for them to need make. >> How do you build 'make'? > > You use the previous version of make and a C compiler. And you do the same for that 'A' language. > How do you build your C compiler? It's written in my language M. The compiler for M is written in my interpreted language Q. The bytecode compiler and interpreter for Q is written in M. If I want someone else to build it, I transpile from M to C, do some special processing which puts the sources (and support files such as standard headers needed to run it, not build it) into one .c source file. Then people build it just like they might do hello.c. No make needed. >> This is completely typical of my experience with make files. (This >> makefile is here: https://pastebin.com/raw/Qz8QAiuS. It certainly >> looks like a language to me.) > > > Use a unix system! Look, the problem we're trying to solve is very simple: what subsets of the supplied .c files need to be compiled to build the required set of binaries. Because certain people insist on encoding this info in make-file syntax, some of us have to take the drastic step of throwing away our current OS, and all the software and know-how built up with them, just because of of this minor point? Remember the other part of the problem is trying to build software on Windows. If there is no Windows, there is no point. OK, I'll throw down this challenge: access the Tiny C/Github [actually http://repo.or.cz/tinycc.git], and write me a batch file, to run in the same directory as the supplied makefile, that will let me build TCC for Windows, in a configurations that targets Windows (and say x64). If makefiles are so ludicrously simple, it should be a piece of cake. > You have so many choices: linux, freebsd, openbsd, darwin, illumos, etc. That's part of the problem. > I've compiled linux on an old Pentium laptop (13 hours), and on a new > Athlon system (5 minutes). (written in C). How many Loc? I've got a version somewhere that is 21Mloc, but I've seen a video that says only 5% of it is compiled for any one configuration. So that's 1Mloc in 5 minutes for your best timing, which brings it in at about 17Klps. Not too terrible (and we don't how many lines are repeatedly compiled as headers, nor whether that 5% excluded lines that are conditional code if false brances, but still need to be scanned; it's a C thing). (I don't know where to start in building those sources, how to verify any results, nor how to test it. It's a problem in information.) > Long compilation times are also influenced by the language; for example, > if you use a lot of templates in C++ programs, this will take more > compilation time (templates are executed at compilation time!). A bad decision of C++ to define so many crucial language features in the language itself. Not when people tend to develop those features at impractical scales. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2018-03-15 08:59 +0100 |
| Message-ID | <m28tatrcpu.fsf@informatimago.com> |
| In reply to | #3906 |
bartc <bc@freeuk.com> writes:
>> make is a POSIX standard tool!
>> http://pubs.opengroup.org/onlinepubs/007904975/utilities/make.html
>> You can assume it is present on the system, so you can provide POSIX
>> makefiles and be confident that the users will be able to compile your
>> programs.
>
> What does that mean?
>
> If I type 'make' on Windows, it usually says 'file not found'.
This is why MS-Windows is not a POSIX system, and why you should not use
MS-Windows.
>> No, but I can blame you for using MS-Windows! DUH! Don't!
>> I mean the reason why you shouldn't use MS-Windows is because it's a
>> poor POSIX platform.
>
> What's POSIX got to do with anything with anything being discussed?
See above.
> But clearly, it sounds like something that originated in Unix, that
> might have a been good fit for how Unix works, but a poor one for
> Windows.
>
> As it happens, I didn't choose Windows, my customers did, because it
> in the early 90s is was very easy to buy Windows machines off the
> shelf, completing with fully working peripherals, and much harder with
> Unix machines.
>
> And also easier to run additional software, not just mine. Or to
> anything really because everyone had them.
>
> But I don't remember having any build problems under Windows that
> necessitated my requiring the use of makefiles or make utilities.
Then why are you trying to compile and run unix or posix software on
MS-Windows? Stay with MS-Windows software.
>>> This is completely typical of my experience with make files. (This
>>> makefile is here: https://pastebin.com/raw/Qz8QAiuS. It certainly
>>> looks like a language to me.)
>>
>>
>> Use a unix system!
>
> Look, the problem we're trying to solve is very simple: what subsets
> of the supplied .c files need to be compiled to build the required set
> of binaries.
>
> Because certain people insist on encoding this info in make-file
> syntax, some of us have to take the drastic step of throwing away our
> current OS, and all the software and know-how built up with them, just
> because of of this minor point?
Yes, that would be the best solution.
However, notice that it is very easy to extract that information from
makefiles. Even without having to parse and interpret them yourself.
You can use the make -MMD option so that gcc generates a .d file with
all the dependencies. Then you can just cat all the *.d files and use
those dependencies.
# [pjb@despina :0.0 ensemble]$ cat Makefile
SOURCES=main.c ensemble.c util.c list.c ensemble_bison.c ensemble_flex.c
OBJECTS=$(SOURCES:.c=.o)
INCLUDES = -I.
CFLAGS?=$(INCLUDES)
all:ensemble
ensemble_flex.c: ensemble.flex
flex -o $@ $<
ensemble_bison.c: ensemble.bison
bison -o $@ $<
ensemble_flex.o: ensemble_flex.c util.h
ensemble_bison.o: ensemble_bison.c ensemble.h list.h util.h
util.o:util.c util.h
list.o:list.c list.h util.h
ensemble.o:ensemble.c ensemble.h util.h
main.o:main.c ensemble.h
ensemble:$(OBJECTS)
$(CC) -o $@ $(OBJECTS)
clean:
-rm -rf $(OBJECTS)
-rm -rf ensemble_flex.c ensemble_bison.c
-rm -rf ensemble
test:ensemble
@echo 'Empty set test:'
echo '{}' | ./ensemble
@echo 'Simple test:'
echo '{1,2,3}' | ./ensemble
@echo 'Space test:'
echo ' { 1 , 2 , 3 } ' | ./ensemble
@echo 'Multi-line test:'
(echo '{11111,';echo '22222,';echo '33333}') | ./ensemble
@echo 'Signed test:'
echo '{-1000000000,-2000000,-3000,-4,-0,0,+0,+4,+3000,+2000000,+1000000000}' | ./ensemble
depends:
CFLAGS="$(INCLUDES) -MMD" make
# [pjb@despina :0.0 ensemble]$ make clean depends
rm -rf main.o ensemble.o util.o list.o ensemble_bison.o ensemble_flex.o
rm -rf ensemble_flex.c ensemble_bison.c
rm -rf ensemble
CFLAGS="-I. -MMD" make
make[1]: Entering directory '/Users/pjb/src/c/ensemble'
cc -I. -MMD -c -o main.o main.c
cc -I. -MMD -c -o ensemble.o ensemble.c
cc -I. -MMD -c -o util.o util.c
cc -I. -MMD -c -o list.o list.c
bison -o ensemble_bison.c ensemble.bison
cc -I. -MMD -c -o ensemble_bison.o ensemble_bison.c
flex -o ensemble_flex.c ensemblpe.flex
cc -I. -MMD -c -o ensemble_flex.o ensemble_flex.c
cc -o ensemble main.o ensemble.o util.o list.o ensemble_bison.o ensemble_flex.o
make[1]: Leaving directory '/Users/pjb/src/c/ensemble'
# [pjb@despina :0.0 ensemble]$ cat *.d
ensemble.o: ensemble.c ensemble.h list.h util.h
ensemble_bison.o: ensemble_bison.c list.h util.h ensemble.h
ensemble_flex.o: ensemble_flex.c util.h tokens.h
list.o: list.c list.h util.h
main.o: main.c ensemble.h list.h
util.o: util.c util.h
# [pjb@despina :0.0 ensemble]$
> Remember the other part of the problem is trying to build software on
> Windows. If there is no Windows, there is no point.
>
> OK, I'll throw down this challenge: access the Tiny C/Github [actually
> http://repo.or.cz/tinycc.git], and write me a batch file, to run in
> the same directory as the supplied makefile, that will let me build
> TCC for Windows, in a configurations that targets Windows (and say
> x64).
>
> If makefiles are so ludicrously simple, it should be a piece of cake.
Yep.
>> You have so many choices: linux, freebsd, openbsd, darwin, illumos, etc.
>
> That's part of the problem.
No, because in practice, you would just use linux.
--
__Pascal J. Bourguignon
http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-03-15 19:21 +0000 |
| Message-ID | <YIzqC.2691$%a5.755@fx21.am4> |
| In reply to | #3908 |
On 15/03/2018 07:59, Pascal J. Bourguignon wrote: > bartc <bc@freeuk.com> writes: > This is why MS-Windows is not a POSIX system, and why you should not use > MS-Windows. >> What's POSIX got to do with anything with anything being discussed? > > See above. > Then why are you trying to compile and run unix or posix software on > MS-Windows? Stay with MS-Windows software. > Yes, that would be the best solution. [Everyone in the world using Unix] > You can use the make -MMD option (Don't forget that make is not working.) >> If makefiles are so ludicrously simple, it should be a piece of cake. > > Yep. (I notice you didn't attempt my task...) > No, because in practice, you would just use linux. Windows. Linux. Unix. POSIX. This is a language group, not an OS one! The projects I try and build are typically language related and should largely be unaffected by OS, yet you keep dragging this stuff in. Usually you have N files of input and one or more files of output. So there should nothing much more challenging to deal with than file I/O, and that problem was solved decades ago. (There is a cross-platform API called the C standard library, which you don't have to call from C, to take care of that.) The real problem is that Unix people have a developed a dependency for Unix ways of doing things, so that even applications purportedly multi-platform, or small enough not to need a build system, can be troublesome to build outside of Unix. On the other hand, I could upload 4 of my projects right now, that will compile (via any C compiler) and run on either Windows or Linux. I don't stipulate that you need half of Windows to be made available before you could even build any of the problems. (For the programs to be used in certain ways, then sometimes OS-specific details might be needed. But at least you can build the program to play around with it. For example, the C compiler runs on Linux, but the code generated is for x64 and Win64 ABI.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2018-03-16 08:08 +0100 |
| Message-ID | <m2o9jopkfa.fsf@despina.home> |
| In reply to | #3912 |
bartc <bc@freeuk.com> writes: > On 15/03/2018 07:59, Pascal J. Bourguignon wrote: >> bartc <bc@freeuk.com> writes: > >> This is why MS-Windows is not a POSIX system, and why you should not use >> MS-Windows. > >>> What's POSIX got to do with anything with anything being discussed? >> >> See above. > >> Then why are you trying to compile and run unix or posix software on >> MS-Windows? Stay with MS-Windows software. > >> Yes, that would be the best solution. [Everyone in the world using Unix] > >> You can use the make -MMD option Sorry, it's not a make option, but a gcc option. My example made that clear anyways. > (Don't forget that make is not working.) Make is always working. You can always run it in a linux box. Possibly even on a Linux Virtual Box! >> No, because in practice, you would just use linux. > > Windows. Linux. Unix. POSIX. > > This is a language group, not an OS one! System construction is basically outside of the scope of the C language. It's not outside of the scope of some other languages. Perhaps you should change the language? If your compiler infers the sources to be compiled from the #include, then it's doing something wrong that is not specified in C. -- __Pascal J. Bourguignon http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-03-16 11:12 +0000 |
| Message-ID | <aENqC.11479$Il7.8167@fx46.am4> |
| In reply to | #3914 |
On 16/03/2018 07:08, Pascal J. Bourguignon wrote: > bartc <bc@freeuk.com> writes: > >> On 15/03/2018 07:59, Pascal J. Bourguignon wrote: >>> bartc <bc@freeuk.com> writes: >> >>> This is why MS-Windows is not a POSIX system, and why you should not use >>> MS-Windows. >> >>>> What's POSIX got to do with anything with anything being discussed? >>> >>> See above. >> >>> Then why are you trying to compile and run unix or posix software on >>> MS-Windows? Stay with MS-Windows software. >> >>> Yes, that would be the best solution. [Everyone in the world using Unix] >> >>> You can use the make -MMD option > > Sorry, it's not a make option, but a gcc option. My example made that > clear anyways. OK, then it has to be used like this: gcc -c -MMD -ofile.o file.c and it produces file.d which says that file.o depends on file.c - which I already know. For being able to compile a open source project that doesn't have a overview of the program files written in English, this doesn't help. I have one open source project that appears to have 300 .c files. Only some of them might be relevant to my OS, but I don't know. But going through them one by one I established that 158 of them could be compiled with gcc. But I can't get beyond that, as I don't know how to combine sets of those into executables or dlls, or whether there should be more than 158 because files depend on some configuration step, or whether some of the 158 are incorrectly compiled, for the same reason. I'm working in the dark. As for makefiles, there seem to be 17 different variations, mostly targetted at different compilers. So much for make syntax being universal; even if true, it hasn't helped. (And come to over 5000 lines of dense makefile syntax to be maintained.) You're out of luck if your own compiler isn't on the list. This is where an overview in English of how to build a project would be most flexible. >> (Don't forget that make is not working.) > > Make is always working. You can always run it in a linux box. Possibly > even on a Linux Virtual Box! Forget make. You and everybody else seem to be obsessed with it! I just want to compile programs. That is, run a compiler on some source files. When finished doing that, run a linker on the results. You're saying that such a simple task is impossible without a makefile? And that makefiles are so important that people should dump their current OSes and switch to any non-Windows OS to make that possible? I don't know if you really believe that. > >>> No, because in practice, you would just use linux. >> >> Windows. Linux. Unix. POSIX. >> >> This is a language group, not an OS one! > > System construction is basically outside of the scope of the C language. > It's not outside of the scope of some other languages. > Perhaps you should change the language? > > If your compiler infers the sources to be compiled from the #include, > then it's doing something wrong that is not specified in C. The open source projects I try and build are in C. So /I/ am not trying to infer anything. My own projects generally aren't in C. With the languages I use, you /can/ infer the other modules of the application by examining the import statements of the main module. When I do write some small apps in C, then I use a project file just simply lists the source files involved, created from my own knowledge of what they are. This makefile mania is like a disease. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2018-03-16 16:45 +0100 |
| Message-ID | <m2k1ucowhj.fsf@despina.home> |
| In reply to | #3915 |
bartc <bc@freeuk.com> writes: > As for makefiles, there seem to be 17 different variations, mostly > targetted at different compilers. So much for make syntax being > universal; even if true, it hasn't helped. (And come to over 5000 > lines of dense makefile syntax to be maintained.) Nope. There are only two versions: POSIX make, and GNU make that provides interesting extensions. -- __Pascal J. Bourguignon http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | Andy Walker <anw@cuboid.co.uk> |
|---|---|
| Date | 2018-03-16 16:09 +0000 |
| Message-ID | <p8gq7t$1262$1@gioia.aioe.org> |
| In reply to | #3915 |
On 16/03/18 11:12, bartc wrote [to Pascal]: > Forget make. You and everybody else seem to be obsessed with it! Well, I'm not obsessed by it, any more than I'm obsessed by power drills,but it is a useful tool. > I just want to compile programs. That is, run a compiler on some > source files. When finished doing that, run a linker on the results. That, surely, is not all you want to do. You very possibly also want to run regression tests as you update your programs, to install the executable somewhere more accessible to others than private directories, to install documentation, to back-up the files, and perhaps also to tidy up the files, eg removing "*.o", or even to uninstall the program. ... > You're saying that such a simple task is impossible without a > makefile? And that makefiles are so important that people should dump > their current OSes and switch to any non-Windows OS to make that > possible? > I don't know if you really believe that. ... I don't think Pascal is claiming that. But if you want to do something twice, it's usually good practice to record what you did the first time and then be able to say "do that again". That is what "make" does. You tell it once, in the "Makefile", how to [eg] install your program, not forgetting to update manual entries and documentation, and to make sure these all have the right permissions and owners, and then you type "make install" whenever you want to do it again -- and you don't have to remember all the details. Yes, you could write little scripts for all these things; "make" just tidies the whole process into one simple file. Well, it's simple if what you want to do is simple; it can get messy if [but only if] you want to compile one same source across several machines and OS's with varying include files and the like. But if so, that's mess you would have anyway. There is the further advantage that "make" already understands quite a lot [and can be programmed to understand more] by way of dependencies and of how to compile code. So the default actions are surprisingly often all you need. FWIW, I do have a little sympathy for your standpoint. As "make" was supplied with V7 Unix, it was a nice simple command, and the manual and documentation were likewise. But over the decades, it has accreted a whole pile of bells and whistles, all no doubt added by someone who wanted them; but the simplicity has been lost [though the simple things at least still work]. It's like the power drill that now comes with zillions of attachments when all you want it for is to make holes. -- Andy Walker, Nottingham.
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2018-03-16 18:42 +0100 |
| Message-ID | <m2fu4zq5ly.fsf@despina.home> |
| In reply to | #3917 |
Andy Walker <anw@cuboid.co.uk> writes: > On 16/03/18 11:12, bartc wrote [to Pascal]: >> Forget make. You and everybody else seem to be obsessed with it! > > FWIW, I do have a little sympathy for your standpoint. As "make" > was supplied with V7 Unix, it was a nice simple command, and the manual > and documentation were likewise. But over the decades, it has accreted > a whole pile of bells and whistles, all no doubt added by someone who > wanted them; but the simplicity has been lost [though the simple things > at least still work]. It's like the power drill that now comes with > zillions of attachments when all you want it for is to make holes. The problem is that once you say that make is not what you need, as I mentionned before, you start to write your own solution to the same problem. Already there are more than half a dozen different variants of make, and more than twenty other build systems (some language specific, some platform specific). This is really a big mess. You end up with code bases where half a dozen different build systems are used and interbraided in a very inefficient and brittle mess. So just say NO! Use GNU make and kill all the others! -- __Pascal J. Bourguignon http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-03-17 18:32 +0000 |
| Message-ID | <8bdrC.101673$kF1.42216@fx41.am4> |
| In reply to | #3917 |
On 16/03/2018 16:09, Andy Walker wrote: > On 16/03/18 11:12, bartc wrote [to Pascal]: >> Forget make. You and everybody else seem to be obsessed with it! > > Well, I'm not obsessed by it, any more than I'm obsessed by power > drills,but it is a useful tool. > >> I just want to compile programs. That is, run a compiler on some >> source files. When finished doing that, run a linker on the results. > > That, surely, is not all you want to do. You very possibly also > want to run regression tests as you update your programs, to install the > executable somewhere more accessible to others than private directories, > to install documentation, to back-up the files, and perhaps also to tidy > up the files, eg removing "*.o", or even to uninstall the program. ... A lot of this I wouldn't consider to be the remit of a system to translate source code to executable. >> You're saying that such a simple task is impossible without a >> makefile? And that makefiles are so important that people should dump >> their current OSes and switch to any non-Windows OS to make that >> possible? >> I don't know if you really believe that. > > ... I don't think Pascal is claiming that. But if you want to do > something twice, it's usually good practice to record what you did the > first time and then be able to say "do that again". That is what "make" > does. You tell it once, in the "Makefile", how to [eg] install your > program, And installation is a separate process. IME, of getting an already built application in binary format on some distribution medium, onto the user's machine in usable form. not forgetting to update manual entries and documentation, What does make know about where I keep my documentation? Or does it assume everyone in the world is a Unix user? Yesterday I went to some trouble to install a new gcc with a working make program. I tried it on one project, and it turned out the makefile was only for Unix-like systems, as it needed ./configure to be run (this was on Windows). However there was a .bat file supplied for use under Windows (which I hadn't spotted) and that eventually worked. It was also 1/4 the size of configure+makefile, and clear enough that I could figure how to manually compile the core program, and hence how to apply my own compiler. I need certain information, and the makefile fanatics want to do their utmost to hide it from me. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2018-03-17 21:37 +0100 |
| Message-ID | <m2bmfmpheg.fsf@despina.home> |
| In reply to | #3921 |
bartc <bc@freeuk.com> writes: > On 16/03/2018 16:09, Andy Walker wrote: >> On 16/03/18 11:12, bartc wrote [to Pascal]: >>> Forget make. You and everybody else seem to be obsessed with it! >> >> Well, I'm not obsessed by it, any more than I'm obsessed by power >> drills,but it is a useful tool. >> >>> I just want to compile programs. That is, run a compiler on some >>> source files. When finished doing that, run a linker on the results. >> >> That, surely, is not all you want to do. You very possibly also >> want to run regression tests as you update your programs, to install the >> executable somewhere more accessible to others than private directories, >> to install documentation, to back-up the files, and perhaps also to tidy >> up the files, eg removing "*.o", or even to uninstall the program. ... > > A lot of this I wouldn't consider to be the remit of a system to > translate source code to executable. > >>> You're saying that such a simple task is impossible without a >>> makefile? And that makefiles are so important that people should dump >>> their current OSes and switch to any non-Windows OS to make that >>> possible? >>> I don't know if you really believe that. >> >> ... I don't think Pascal is claiming that. But if you want to do >> something twice, it's usually good practice to record what you did the >> first time and then be able to say "do that again". That is what "make" >> does. You tell it once, in the "Makefile", how to [eg] install your >> program, > > And installation is a separate process. IME, of getting an already > built application in binary format on some distribution medium, onto > the user's machine in usable form. > > > not forgetting to update manual entries and documentation, > > What does make know about where I keep my documentation? Or does it > assume everyone in the world is a Unix user? Stop being an idiot! Make is not specfic to unix. On the other hand, processing a bunch of source files to obtain a bunch of target files is a generic operation. Whether it's building a executable from object files, themselves obtained from source files, or it's building a pdf file from latex or restructuredText files, it's the same kind of operation. I already explained to you, that the relationship between the target files and the source files can be described as a directed arc of a graph (a dependency), labelled by the commands used to process the source files and produce the target files. And when you have complex systems, you have a lot of sources and targets, and you don't want to re-process everything when you modify a small part of the sources. So you need a tool to walk that dependency graph, and schedule only the needed commands. This kind of processing of a bunch of source files into a bunch of target files is totally generic, and non-specfic to a platform or a given process. This is why make is nice and universal, and the reason why it is a standard POSIX tool! > Yesterday I went to some trouble to install a new gcc with a working > make program. I tried it on one project, and it turned out the > makefile was only for Unix-like systems, as it needed ./configure to > be run (this was on Windows). Again, MS-Windows is not POSIX, so it should be rejected. > However there was a .bat file supplied for use under Windows (which I > hadn't spotted) and that eventually worked. It was also 1/4 the size > of configure+makefile, and clear enough that I could figure how to > manually compile the core program, and hence how to apply my own > compiler. > > I need certain information, and the makefile fanatics want to do their > utmost to hide it from me. Notably, the information you need, is the dependency graph, and the labelled commands. It's true that if you want to support non-POSIX systems, you cannot just restrict yourselfl to POSIX commands. This is what tools like maven or ant try to solve, by way of abstracting the commands with platform specific implementations or plugins. But there will always be another unsupported platform, or another command for which there's no plugin, or that doesn't make sense on some platform. So basically, it doesn't solve the problem any better than make. -- __Pascal J. Bourguignon http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-03-17 21:00 +0000 |
| Message-ID | <OlfrC.17759$Cz7.7546@fx10.am4> |
| In reply to | #3922 |
On 17/03/2018 20:37, Pascal J. Bourguignon wrote: > bartc <bc@freeuk.com> writes: > Make is not specfic to unix. > > On the other hand, processing a bunch of source files to obtain a bunch > of target files is a generic operation. OK. Remember that statement.... >> Yesterday I went to some trouble to install a new gcc with a working >> make program. I tried it on one project, and it turned out the >> makefile was only for Unix-like systems, as it needed ./configure to >> be run (this was on Windows). > > Again, MS-Windows is not POSIX, so it should be rejected. .... because now, it's apparently no longer generic: you need something called POSIX to do it, and you can no longer do it on MS_Windows. > It's true that if you want to support non-POSIX systems, you cannot just > restrict yourselfl to POSIX commands. > > This is what tools like maven or ant try to solve, by way of abstracting > the commands with platform specific implementations or plugins. But > there will always be another unsupported platform I would hardly consider MS-Windows an obscure, poorly supported platform. (Wasn't this the world's most popular OS at one time? It might still be, on PCs.) How on earth did people manage without a POSIX conformant 'make'? Well in this case they managed it with a script, written in Batch, which was much smaller, simpler and more readable than the configure/makefile option. -- bartc
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.lang.misc
csiph-web