Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #129717 > unrolled thread
| Started by | bartc <bc@freeuk.com> |
|---|---|
| First post | 2018-04-25 16:21 +0100 |
| Last post | 2018-04-27 19:37 +0100 |
| Articles | 20 on this page of 104 — 27 participants |
Back to article view | Back to comp.lang.c
gcc_centric C code bartc <bc@freeuk.com> - 2018-04-25 16:21 +0100
gcc_centric C code Chad <cdalten@gmail.com> - 2018-04-25 08:34 -0700
Re: gcc_centric C code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-04-25 16:41 +0100
Re: gcc_centric C code Spiros Bousbouras <spibou@gmail.com> - 2018-04-25 16:19 +0000
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-25 18:02 +0100
Re: gcc_centric C code Nick Bowler <nbowler@draconx.ca> - 2018-04-25 17:15 +0000
Re: gcc_centric C code Robert Wessel <robertwessel2@yahoo.com> - 2018-04-25 12:33 -0500
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-25 20:51 +0100
Re: gcc_centric C code supercat@casperkitty.com - 2018-04-25 13:01 -0700
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-25 21:21 +0100
Re: gcc_centric C code jameskuyper@verizon.net - 2018-04-25 13:45 -0700
Re: gcc_centric C code Spiros Bousbouras <spibou@gmail.com> - 2018-04-25 17:20 +0000
Re: gcc_centric C code supercat@casperkitty.com - 2018-04-25 10:30 -0700
Re: gcc_centric C code Robert Wessel <robertwessel2@yahoo.com> - 2018-04-25 12:35 -0500
Re: gcc_centric C code Keith Thompson <kst-u@mib.org> - 2018-04-25 10:54 -0700
Re: gcc_centric C code Philipp Klaus Krause <pkk@spth.de> - 2018-04-25 20:27 +0200
Re: gcc_centric C code Keith Thompson <kst-u@mib.org> - 2018-04-25 12:38 -0700
Re: gcc_centric C code Robert Wessel <robertwessel2@yahoo.com> - 2018-04-25 19:53 -0500
Re: gcc_centric C code Keith Thompson <kst-u@mib.org> - 2018-04-25 18:13 -0700
Re: gcc_centric C code Nick Bowler <nbowler@draconx.ca> - 2018-04-26 15:16 +0000
Re: gcc_centric C code Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-27 08:17 -0700
Re: gcc_centric C code Philipp Klaus Krause <pkk@spth.de> - 2018-04-26 08:03 +0200
Re: gcc_centric C code Nick Bowler <nbowler@draconx.ca> - 2018-04-26 14:30 +0000
Re: gcc_centric C code jameskuyper@verizon.net - 2018-04-26 08:26 -0700
Re: gcc_centric C code Philipp Klaus Krause <pkk@spth.de> - 2018-04-26 19:04 +0200
Re: gcc_centric C code Ian Collins <ian-news@hotmail.com> - 2018-04-27 07:48 +1200
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-26 21:08 +0100
Re: gcc_centric C code Ian Collins <ian-news@hotmail.com> - 2018-04-27 08:18 +1200
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-26 21:44 +0100
Re: gcc_centric C code Ian Collins <ian-news@hotmail.com> - 2018-04-27 09:01 +1200
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-26 23:16 +0100
Re: gcc_centric C code Ian Collins <ian-news@hotmail.com> - 2018-04-27 10:27 +1200
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-26 23:48 +0100
Re: gcc_centric C code Ian Collins <ian-news@hotmail.com> - 2018-04-27 20:41 +1200
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-27 11:51 +0100
Re: gcc_centric C code Ian Collins <ian-news@hotmail.com> - 2018-04-28 07:32 +1200
Re: gcc_centric C code Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-28 04:34 -0700
Re: gcc_centric C code Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-26 23:05 -0700
Re: gcc_centric C code jacobnavia <jacob@jacob.remcomp.fr> - 2018-04-27 00:52 +0200
Re: gcc_centric C code supercat@casperkitty.com - 2018-04-26 16:23 -0700
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-28 11:24 +0100
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-28 01:42 +0100
Re: gcc_centric C code Dan Purgert <dan@djph.net> - 2018-04-26 21:40 +0000
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-26 23:34 +0100
Re: gcc_centric C code "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-04-26 14:13 -0700
Re: gcc_centric C code "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-04-26 14:16 -0700
Re: gcc_centric C code Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-27 08:08 -0700
Re: gcc_centric C code Keith Thompson <kst-u@mib.org> - 2018-04-27 09:11 -0700
Re: gcc_centric C code supercat@casperkitty.com - 2018-04-27 09:26 -0700
Re: gcc_centric C code Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-27 09:49 -0700
Re: gcc_centric C code supercat@casperkitty.com - 2018-04-25 12:31 -0700
Re: gcc_centric C code Nick Bowler <nbowler@draconx.ca> - 2018-04-25 20:13 +0000
Re: gcc_centric C code supercat@casperkitty.com - 2018-04-25 13:50 -0700
Re: gcc_centric C code Nick Bowler <nbowler@draconx.ca> - 2018-04-25 18:02 +0000
Re: gcc_centric C code Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-25 22:39 -0700
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-25 18:36 +0100
Re: gcc_centric C code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-04-25 23:15 +0100
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-26 02:02 +0100
Re: gcc_centric C code Keith Thompson <kst-u@mib.org> - 2018-04-25 18:28 -0700
Re: gcc_centric C code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-04-26 11:45 +0100
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-26 14:53 +0100
Re: gcc_centric C code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-04-26 23:38 +0100
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-27 00:31 +0100
Re: gcc_centric C code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-04-27 00:47 +0100
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-27 02:28 +0100
Re: gcc_centric C code Thiago Adams <thiago.adams@gmail.com> - 2018-04-27 03:44 -0700
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-05-03 13:57 +0100
Re: gcc_centric C code Thiago Adams <thiago.adams@gmail.com> - 2018-05-03 11:02 -0700
Re: gcc_centric C code Thiago Adams <thiago.adams@gmail.com> - 2018-05-03 11:07 -0700
Re: gcc_centric C code Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-03 11:13 -0700
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-05-03 19:50 +0100
Re: gcc_centric C code Thiago Adams <thiago.adams@gmail.com> - 2018-05-03 13:37 -0700
Re: gcc_centric C code Thiago Adams <thiago.adams@gmail.com> - 2018-05-03 13:44 -0700
Re: gcc_centric C code Thiago Adams <thiago.adams@gmail.com> - 2018-05-11 10:25 -0700
Re: gcc_centric C code Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-26 07:01 -0700
Re: Clearly everyone else likes to do things the hard way Noob <root@127.0.0.1> - 2018-04-26 14:51 +0200
Re: Clearly everyone else likes to do things the hard way mark.bluemel@gmail.com - 2018-04-26 07:09 -0700
Re: Clearly everyone else likes to do things the hard way gazelle@shell.xmission.com (Kenny McCormack) - 2018-04-26 17:05 +0000
Re: Clearly everyone else likes to do things the hard way bartc <bc@freeuk.com> - 2018-04-26 18:38 +0100
Re: Clearly everyone else likes to do things the hard way 1alvinalbrecht1@gmail.com - 2018-04-26 11:34 -0700
Re: Clearly everyone else likes to do things the hard way bartc <bc@freeuk.com> - 2018-04-26 21:36 +0100
Re: Clearly everyone else likes to do things the hard way C W Rose <cwr@seckford.org> - 2018-04-27 19:23 +0100
Re: Clearly everyone else likes to do things the hard way bartc <bc@freeuk.com> - 2018-04-28 14:34 +0100
Re: Clearly everyone else likes to do things the hard way Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-28 10:32 -0700
Re: Clearly everyone else likes to do things the hard way supercat@casperkitty.com - 2018-04-30 10:16 -0700
Re: Clearly everyone else likes to do things the hard way bartc <bc@freeuk.com> - 2018-04-30 19:41 +0100
Re: Clearly everyone else likes to do things the hard way supercat@casperkitty.com - 2018-04-30 12:11 -0700
Re: Clearly everyone else likes to do things the hard way scott@slp53.sl.home (Scott Lurndal) - 2018-04-30 19:14 +0000
Re: Clearly everyone else likes to do things the hard way scott@slp53.sl.home (Scott Lurndal) - 2018-04-30 19:12 +0000
Re: Clearly everyone else likes to do things the hard way bartc <bc@freeuk.com> - 2018-04-30 21:19 +0100
Re: Clearly everyone else likes to do things the hard way Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-30 19:23 -0700
Re: Clearly everyone else likes to do things the hard way Philipp Klaus Krause <pkk@spth.de> - 2018-04-26 19:45 +0200
Re: gcc_centric C code luser droog <luser.droog@gmail.com> - 2018-04-25 21:56 -0700
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-26 11:06 +0100
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-26 11:27 +0100
Re: gcc_centric C code antispam@math.uni.wroc.pl - 2018-04-26 17:00 +0000
Re: gcc_centric C code Thiago Adams <thiago.adams@gmail.com> - 2018-04-25 09:26 -0700
Re: gcc_centric C code Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-04-26 12:39 +0000
Re: gcc_centric C code gazelle@shell.xmission.com (Kenny McCormack) - 2018-04-26 13:09 +0000
Re: gcc_centric C code Wouter Verhelst <w@uter.be> - 2018-04-26 13:26 +0200
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-26 18:03 +0100
Re: gcc_centric C code Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-26 14:32 -0700
Re: gcc_centric C code Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-27 09:41 -0700
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-27 19:37 +0100
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-26 14:53 +0100 |
| Message-ID | <pRkEC.61348$EL2.17465@fx37.am4> |
| In reply to | #129779 |
On 26/04/2018 11:45, Ben Bacarisse wrote:
> bartc <bc@freeuk.com> writes:
>> I didn't choose not to. I just can't because I don't know how, and
>> when I've tried in the past, the results were hit and miss, usually
>> miss, so now I don't even bother.
>
> Ah, I see. That means you have no idea what the build system might
> bring to the party,
Did you read about my attempt to use VS2017? You accuse me of
conveniently ignoring things you post, but you do the same!
and thus no idea what your numbers show. For all
> you know the files you took a copy of may include complete or partial
> configuration for one or other compiler, yes?
Look at my figures again. 47 out of 48 files compiled with gcc (in that
47 .obj files were written). One file didn't because of a missing header
that even gcc can't conjure up. None of the other compilers could match
that.
Now look at my subject line (which should be gcc-centric); see what I'm
getting at? Source codes are optimised for gcc and can cause all sorts
of problems with other compilers. Using configuration may or may not fix
those.
>> Here's one such error:
>
> The errors you get on an un-configured or partially configured source
> are not interesting (well, not to me, you seem to be interested in
> them). In particular they don't help answer the questions I asked.
You seem to be deliberately ignoring the errors that are not to do with
configuration. Or you are not interested at all in attempting what
appears to be an alien task in this group of 'compiling a .c source file
with a C compiler'. Not unless it's in some automatic script.
I already said I can't use such methods because (a) I'm on Windows (b)
The Visual Studio method which I DID try didn't work.
I mentioned two errors that are not configuration ones:
(1) The out-of-order use 'size_t' when gcc/MSVC were not used
(2) The assignment of NULL (void*) to an int, which was ignored by gcc
(not even a warning, and it did see that line), but not by other compilers.
>> Just as a reminder of how it should be done IMO; pcc64.c
>
> Can you link to this file? It would be interesting so see just how much
> simpler this program is than the one you posted about.
It's simpler in that it's presented as one C file. And I've said it's
1/4 the size of those 48 .c files plus headers.
(There is a companion program qcc64.c, a byte-code compiler, about the
same size. Together they come to about 40Kloc, half the size of this
directory. However the two kinds of interpreters do somewhat different
jobs. My language is richer than Postscript, but has a very meagre
library built-in and no graphics.)
>> No hassle; no fuss; IT JUST WORKS.
>
> It doesn't work for me.
I thought you said you couldn't find that file?
You need bcc.exe and mxa.exe (both can be found in
http://home.freeuk.com/bcas/bcc.zip)
The source file is: http://home.freeuk.com/bcas/pcc64.c.
The test input for pcc64 is: http://home.freeuk.com/bcas/hello.pc.
The programs are for 64-bit WINDOWS (either that, or 'wine' under Linux):
bcc pcc64 # compile pcc64.c to pcc64.asm
mxa pcc64 # assemble pcc64.asm and write out as pcc64.exe
pcc64 hello # run pcc64.exe on hello.pc
pcc64 # will give odd message with no input (I can
# give info but if you get this far, you've
# proved my point)
Likely problems:
* AV issues; either turn off AV or wait for files to be checked
This version of pcc64.c is OS-neutral to allow the Linux option below
(which is the reason for the odd message as it attempts to read the .exe
file for an embedded .pc file, but it needs OS support).
Alternatively pcc64.c can be compiled with any 64-bit C compiler: I've
built and run it these compilers just now (I thought I'd been and done
with this palaver, but one last time):
bcc Windows 64-bit x64 as above
Tiny C Windows 64-bit x64
gcc Windows 64-bit x64
MSVC Windows 64-bit x64
Pelles C Windows 64-bit x64
gcc Linux 64-bit x64
DMC Windows 32-bit x86 pcc32.c (no 64-bit version)
lccwin Windows 32-bit x86 pcc32.c (64-bit version doesn't run)
gcc Linux 32-bit ARM pcc32.c (no 64-bit ARM machine to hand)
Now look inside the source to see how many #ifdefs there are to make
this possible.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-04-26 23:38 +0100 |
| Message-ID | <877eottwxw.fsf@bsb.me.uk> |
| In reply to | #129786 |
bartc <bc@freeuk.com> writes: > On 26/04/2018 11:45, Ben Bacarisse wrote: >> bartc <bc@freeuk.com> writes: >>> Just as a reminder of how it should be done IMO; pcc64.c >> >> Can you link to this file? It would be interesting so see just how much >> simpler this program is than the one you posted about. > > It's simpler in that it's presented as one C file. It's simpler for other reasons too. >>> No hassle; no fuss; IT JUST WORKS. >> >> It doesn't work for me. > > I thought you said you couldn't find that file? > > You need bcc.exe and mxa.exe (both can be found in > http://home.freeuk.com/bcas/bcc.zip) > > The source file is: http://home.freeuk.com/bcas/pcc64.c. > > The test input for pcc64 is: http://home.freeuk.com/bcas/hello.pc. > > The programs are for 64-bit WINDOWS (either that, or 'wine' under > Linux): A build using a specific compiler, linker and run-time emulation (if needed) is really beside the point. No one would use any configuration system if they could assume all of those, so it's what you go on to say that is more significant: > Alternatively pcc64.c can be compiled with any 64-bit C compiler: I've > built and run it these compilers just now (I thought I'd been and done > with this palaver, but one last time): > > bcc Windows 64-bit x64 as above > Tiny C Windows 64-bit x64 > gcc Windows 64-bit x64 > MSVC Windows 64-bit x64cc > Pelles C Windows 64-bit x64 > > gcc Linux 64-bit x64 > > DMC Windows 32-bit x86 pcc32.c (no 64-bit version) > lccwin Windows 32-bit x86 pcc32.c (64-bit version doesn't run) > gcc Linux 32-bit ARM pcc32.c (no 64-bit ARM machine to hand) > > Now look inside the source to see how many #ifdefs there are to make > this possible. It's an odd comparison. First off, pcc64.c does not look like source code -- it looks like the output of some other program so the construction of the executable from editable sources is not quite as simple as you are suggesting. There is at least one more stage. But more significantly, the program is probably not highly system dependent, whereas I think the project you originally picked is. Surely an example of "how it should be done" should be doing the same "it"? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-27 00:31 +0100 |
| Message-ID | <GitEC.125485$CH6.92773@fx01.am4> |
| In reply to | #129829 |
On 26/04/2018 23:38, Ben Bacarisse wrote: > bartc <bc@freeuk.com> writes: >> Now look inside the source to see how many #ifdefs there are to make >> this possible. > > It's an odd comparison. First off, pcc64.c does not look like source > code -- it looks like the output of some other program so the > construction of the executable from editable sources is not quite as > simple as you are suggesting. There is at least one more stage. It doesn't matter, it can count as source in that you can choose your compiler, target and options; peruse the comments and make a few tweaks. So several different executables can be generated from the same file. And there are fewer problems getting .c files past AV software. sqlite3.c does a similar thing, but mine looks better even though sqlite used C as a start point; mine didn't. > But more significantly, the program is probably not highly system > dependent, whereas I think the project you originally picked is. Surely > an example of "how it should be done" should be doing the same "it"? I deliberately made it system independent. Certainly that particular file. In practice there may need to be Windows and Linux versions (I dislike conditional code inside programs), or split into two parts. But this is still about streamlined source formats for distribution. (For this project, it only needs two functions different between Windows and Linux; most OS-dependent stuff happens inside byte-code programs.) The Postscript project, as I understand it, takes a source file as input, and executes the code, with the output being rendered graphics in a variety of formats, including the host machine's display which would, for me, be the main difference between Windows and Linux versions. But then that part could also use a cross-platform external library. Anyway, I don't see enough show-stoppers there would warrant that amount of automated configuration, even if this is being done with true sources. ------------ Let me put it this way: if /I/ was to write an application in C along these lines, and I decided to make it open source, do you think I would hide the build details behind autoconf, configure scripts, makefiles or VS project files? If not, do you think my solution would be more elaborate than those? -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-04-27 00:47 +0100 |
| Message-ID | <87muxpsf7g.fsf@bsb.me.uk> |
| In reply to | #129835 |
bartc <bc@freeuk.com> writes: > On 26/04/2018 23:38, Ben Bacarisse wrote: >> bartc <bc@freeuk.com> writes: > >>> Now look inside the source to see how many #ifdefs there are to make >>> this possible. >> >> It's an odd comparison. First off, pcc64.c does not look like source >> code -- it looks like the output of some other program so the >> construction of the executable from editable sources is not quite as >> simple as you are suggesting. There is at least one more stage. > > It doesn't matter, it can count as source in that you can choose your > compiler, target and options; peruse the comments and make a few > tweaks. So several different executables can be generated from the > same file. It matters if your point is about the simplicity of building from sources. I thought that was a big part of what you were saying. > sqlite3.c does a similar thing, but mine looks better even though > sqlite used C as a start point; mine didn't. Er, exactly. sqlite does not build the C code from some other sources. > Let me put it this way: if /I/ was to write an application in C along > these lines, and I decided to make it open source, do you think I > would hide the build details behind autoconf, configure scripts, > makefiles or VS project files? I'm guessing no. > If not, do you think my solution would be more elaborate than those? It's unlikely that you would attempt to solve the problems that autoconf was designed to address, so I can not imagine you would need a system anything like as complicated. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-27 02:28 +0100 |
| Message-ID | <51vEC.124179$jZ.41492@fx20.am4> |
| In reply to | #129836 |
On 27/04/2018 00:47, Ben Bacarisse wrote: > bartc <bc@freeuk.com> writes: > > It matters if your point is about the simplicity of building from > sources. I thought that was a big part of what you were saying. The theme is about writing C programs which are not fussy about which compilers are used. I was reluctantly dragged into talking about build systems (horrible bloody things), but yes they can be part of the problem as people will use them to sort out some of the dependency issues. Or they will just use them anyway. >> sqlite3.c does a similar thing, but mine looks better even though >> sqlite used C as a start point; mine didn't. > > Er, exactly. sqlite does not build the C code from some other sources. That doesn't matter; this is not about my specific sources, which were just examples of programs that are not bothered about compiler details. A genuine single source file would be nice, but a simple self-contained set of C files would be fine too: "compile all those and then just link the lot". With managing multiple 'true' source files, one of my languages can combine all dependent source files of a project into a composite source file (not a single module), and it can compile in that form too. Handy for distributing (it is text so AV-friendly) and the files can be extracted too. That will be applied to a second language soon. And it /could/ be applied to C, except (1) there is no module system to automatically locate all the source files; (2) such a composite source file would not be compatible with existing C compilers. So solutions for tidily managing the files of a project are a little harder. >> If not, do you think my solution would be more elaborate than those? > > It's unlikely that you would attempt to solve the problems that autoconf > was designed to address, so I can not imagine you would need a system > anything like as complicated. OK. Someone at last has admitted it can be complicated! -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2018-04-27 03:44 -0700 |
| Message-ID | <68e9d72e-2a62-49dd-bde4-d23e58c8d2d7@googlegroups.com> |
| In reply to | #129836 |
On Thursday, April 26, 2018 at 8:47:24 PM UTC-3, Ben Bacarisse wrote: > bartc <> writes: > > > On 26/04/2018 23:38, Ben Bacarisse wrote: > >> bartc <> writes: > > > >>> Now look inside the source to see how many #ifdefs there are to make > >>> this possible. > >> > >> It's an odd comparison. First off, pcc64.c does not look like source > >> code -- it looks like the output of some other program so the > >> construction of the executable from editable sources is not quite as > >> simple as you are suggesting. There is at least one more stage. > > > > It doesn't matter, it can count as source in that you can choose your > > compiler, target and options; peruse the comments and make a few > > tweaks. So several different executables can be generated from the > > same file. > > It matters if your point is about the simplicity of building from > sources. I thought that was a big part of what you were saying. > > > sqlite3.c does a similar thing, but mine looks better even though > > sqlite used C as a start point; mine didn't. > > Er, exactly. sqlite does not build the C code from some other sources. > > > Let me put it this way: if /I/ was to write an application in C along > > these lines, and I decided to make it open source, do you think I > > would hide the build details behind autoconf, configure scripts, > > makefiles or VS project files? > > I'm guessing no. > > > If not, do you think my solution would be more elaborate than those? > > It's unlikely that you would attempt to solve the problems that autoconf > was designed to address, so I can not imagine you would need a system > anything like as complicated. > I agree with Bart in relation that build systems are too complicated. I have already posted my suggestion here, I will put it again. First make pre-compiled headers part of the standard. Then add "#source" to the standard to inform with c files needs to be compiled. Sample: file1.c file2.c build.c And build.c is something like: #ifdef compiler1 //options ... #elif compiler2 #... #endif #source "file1.c" #source "file2.c" ---------- to build in any platform we could just execute: compiler build.c -out program.exe There is nothing about "compile only files that have been changed" this is not the purpose. My suggestion is also add #dir for include directories and #lib for libraries. (everything required to build). In other words, everything expressed by the command line, also can be expressed inside the build.c. You can choose use command line or put it in a file. Consequently, some command line (the ones that can be expressed in the source), also can be standardized. Compilers can have their options, this is not a problem and its is not necessary to make all options standard. This really makes sense to me. What do you think?
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-03 13:57 +0100 |
| Message-ID | <5HDGC.113303$uL.7590@fx15.am4> |
| In reply to | #129850 |
On 27/04/2018 11:44, Thiago Adams wrote: > First make pre-compiled headers part of the standard. > > Then add "#source" to the standard to inform with c files > needs to be compiled. > > Sample: > > file1.c > file2.c > build.c > > And build.c is something like: > > #ifdef compiler1 > //options > ... > #elif compiler2 > #... > #endif > > #source "file1.c" > #source "file2.c" > > > ---------- > > to build in any platform we could just > execute: > > compiler build.c -out program.exe When I was more enthusiastic at the start of my C compiler development, I was also thinking about a similar scheme. Then I was thinking of a whole-project compiler, where all modules are known about in a single compiler invocation, and they are compiled together and would share a common symbol table. That introduced the problem of how to make the modules known without resorting to just listing them on the command line. And one way was to use #pragmas. But I didn't like the idea of modifying source code, as you'd have to do if applying this to an existing project. There were a few other problems too, such as how best to deal with 50 instances of windows.h. Anyway in the end it was enough work just to compile one module at a time. Also, extending C wasn't on my agenda. I'm working on these ideas now, but in a different language that can have the necessary requirements built-in (see below). > My suggestion is also add #dir for include directories and #lib > for libraries. (everything required to build). > In other words, everything expressed by the command line, > also can be expressed inside the build.c. You can choose > use command line or put it in a file. (The way it works with my non-C project is: * The lead module of the application is submitted to the compiler * The import statements are used to recursively locate all dependent modules (and /then/ everything is compiled, with each pass scanning all modules before proceeding to the next) * External (to program) functions must be associated with a specific dll library. * The set of dll files referenced can be used to link those libraries without any further input * No imported module (there are no headers) is ever processed more than once for each project build. This is never going to work with C.) > Consequently, some command line (the ones that can be expressed in the source), also can be standardized. Compilers can have their options, > this is not a problem and its is not necessary to make all options standard. > > This really makes sense to me. > What do you think? I think that for C, this can be done within comments (or perhaps #pragmas) rather than special directives. That keeps the code compatible when the build system is not supported. A compiler that knows about them can extract the directives. (Unless build.c is only for this purpose, but then it will be criticised for being just another kind of make file.) One problem for open source, is requiring that someone uses a special compiler, otherwise they have to fall back to traditional build methods. Unless the special processor for build.c can be a small C program that can be simply compiled first. Then /that/ will be criticised for being another version of 'make'! So I think persuading people to move from make (people for whom it happens to work), will be a big problem. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2018-05-03 11:02 -0700 |
| Message-ID | <50b26d75-b11f-4ca9-8ba3-32e2c7785ce0@googlegroups.com> |
| In reply to | #130078 |
On Thursday, May 3, 2018 at 9:57:45 AM UTC-3, Bart wrote: > On 27/04/2018 11:44, Thiago Adams wrote: > > > First make pre-compiled headers part of the standard. > > > > Then add "#source" to the standard to inform with c files > > needs to be compiled. > > > > Sample: > > > > file1.c > > file2.c > > build.c > > > > And build.c is something like: > > > > #ifdef compiler1 > > //options > > ... > > #elif compiler2 > > #... > > #endif > > > > #source "file1.c" > > #source "file2.c" > > > > > > ---------- > > > > to build in any platform we could just > > execute: > > > > compiler build.c -out program.exe > > When I was more enthusiastic at the start of my C compiler development, > I was also thinking about a similar scheme. > > Then I was thinking of a whole-project compiler, where all modules are > known about in a single compiler invocation, and they are compiled > together and would share a common symbol table. > > That introduced the problem of how to make the modules known without > resorting to just listing them on the command line. And one way was to > use #pragmas. > > But I didn't like the idea of modifying source code, as you'd have to do > if applying this to an existing project. This is separated source code. For instance, build.c. You can imagine it as something separated. > There were a few other problems too, such as how best to deal with 50 > instances of windows.h. Anyway in the end it was enough work just to > compile one module at a time. I think this is about pre-compiled headers and also something that can be specified separately. But I think it should be standard. > Also, extending C wasn't on my agenda. I'm working on these ideas now, > but in a different language that can have the necessary requirements > built-in (see below). > > > My suggestion is also add #dir for include directories and #lib > > for libraries. (everything required to build). > > > In other words, everything expressed by the command line, > > also can be expressed inside the build.c. You can choose > > use command line or put it in a file. > > (The way it works with my non-C project is: > > * The lead module of the application is submitted to the compiler > > * The import statements are used to recursively locate all dependent > modules (and /then/ everything is compiled, with each pass scanning > all modules before proceeding to the next) > > * External (to program) functions must be associated > with a specific dll library. > > * The set of dll files referenced can be used to link those libraries > without any further input > > * No imported module (there are no headers) is ever processed more > than once for each project build. > > This is never going to work with C.) > > > Consequently, some command line (the ones that can be expressed in the source), also can be standardized. Compilers can have their options, > > this is not a problem and its is not necessary to make all options standard. > > > > This really makes sense to me. > > What do you think? > > I think that for C, this can be done within comments (or perhaps > #pragmas) rather than special directives. That keeps the code compatible > when the build system is not supported. A compiler that knows about them > can extract the directives. But this also can be an separated file. The good point is to use the preprocessor to make selections of includes compiler etc..using the tools (#ifdef etc) that everyone knows. > (Unless build.c is only for this purpose, but then it will be criticised > for being just another kind of make file.) Yes. > One problem for open source, is requiring that someone uses a special > compiler, otherwise they have to fall back to traditional build methods. > Unless the special processor for build.c can be a small C program that > can be simply compiled first. Then /that/ will be criticised for being > another version of 'make'! > > So I think persuading people to move from make (people for whom it > happens to work), will be a big problem. Yes, before the standardization of #dir, #source .. they could be translated to another tool Cmake maybe?
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2018-05-03 11:07 -0700 |
| Message-ID | <6b847c00-8371-4d22-a747-ea0ecc42f0c3@googlegroups.com> |
| In reply to | #130096 |
On Thursday, May 3, 2018 at 3:03:07 PM UTC-3, Thiago Adams wrote: ... > > So I think persuading people to move from make (people for whom it > > happens to work), will be a big problem. > > Yes, before the standardization of #dir, #source .. they could be translated > to another tool Cmake maybe? The command line also could be generated.
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-03 11:13 -0700 |
| Message-ID | <50fcd23b-56b9-4522-acef-29554382b922@googlegroups.com> |
| In reply to | #130096 |
On Thursday, May 3, 2018 at 11:03:07 AM UTC-7, Thiago Adams wrote: > On Thursday, May 3, 2018 at 9:57:45 AM UTC-3, Bart wrote: > > On 27/04/2018 11:44, Thiago Adams wrote: > > > > > First make pre-compiled headers part of the standard. > > > > > > Then add "#source" to the standard to inform with c files > > > needs to be compiled. > > > > > > Sample: > > > > > > file1.c > > > file2.c > > > build.c > > > > > > And build.c is something like: > > > > > > #ifdef compiler1 > > > //options > > > ... > > > #elif compiler2 > > > #... > > > #endif > > > > > > #source "file1.c" > > > #source "file2.c" > > > > > > > > > ---------- > > > > > > to build in any platform we could just > > > execute: > > > > > > compiler build.c -out program.exe > > > > When I was more enthusiastic at the start of my C compiler development, > > I was also thinking about a similar scheme. > > > > Then I was thinking of a whole-project compiler, where all modules are > > known about in a single compiler invocation, and they are compiled > > together and would share a common symbol table. > > > > That introduced the problem of how to make the modules known without > > resorting to just listing them on the command line. And one way was to > > use #pragmas. > > > > But I didn't like the idea of modifying source code, as you'd have to do > > if applying this to an existing project. > > This is separated source code. For instance, build.c. > You can imagine it as something separated. > > > There were a few other problems too, such as how best to deal with 50 > > instances of windows.h. Anyway in the end it was enough work just to > > compile one module at a time. > > I think this is about pre-compiled headers and also something that > can be specified separately. But I think it should be standard. > > > > Also, extending C wasn't on my agenda. I'm working on these ideas now, > > but in a different language that can have the necessary requirements > > built-in (see below). > > > > > My suggestion is also add #dir for include directories and #lib > > > for libraries. (everything required to build). > > > > > In other words, everything expressed by the command line, > > > also can be expressed inside the build.c. You can choose > > > use command line or put it in a file. > > > > (The way it works with my non-C project is: > > > > * The lead module of the application is submitted to the compiler > > > > * The import statements are used to recursively locate all dependent > > modules (and /then/ everything is compiled, with each pass scanning > > all modules before proceeding to the next) > > > > * External (to program) functions must be associated > > with a specific dll library. > > > > * The set of dll files referenced can be used to link those libraries > > without any further input > > > > * No imported module (there are no headers) is ever processed more > > than once for each project build. > > > > This is never going to work with C.) > > > > > Consequently, some command line (the ones that can be expressed in the source), also can be standardized. Compilers can have their options, > > > this is not a problem and its is not necessary to make all options standard. > > > > > > This really makes sense to me. > > > What do you think? > > > > I think that for C, this can be done within comments (or perhaps > > #pragmas) rather than special directives. That keeps the code compatible > > when the build system is not supported. A compiler that knows about them > > can extract the directives. > > But this also can be an separated file. The good point is to use the > preprocessor to make selections of includes compiler etc..using the > tools (#ifdef etc) that everyone knows. > > > > (Unless build.c is only for this purpose, but then it will be criticised > > for being just another kind of make file.) > > Yes. > > > > One problem for open source, is requiring that someone uses a special > > compiler, otherwise they have to fall back to traditional build methods. > > Unless the special processor for build.c can be a small C program that > > can be simply compiled first. Then /that/ will be criticised for being > > another version of 'make'! > > > > So I think persuading people to move from make (people for whom it > > happens to work), will be a big problem. > > Yes, before the standardization of #dir, #source .. they could be translated > to another tool Cmake maybe? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 If you call getting your ass *kicked hard* left and right every single day by numerous people (and completely trashing your reputation and any reason for anyone to trust anything you have to say - forever) 'trolling', then yeah... he was a good troll. I don't personally subscribe to that definition, I use another term, I call that person a total idiot. > He's lost that ability. Probably too many bad drugs. He's toned down all the zillions of narcissistic, BS threads he used to create but he's really not much different in the honesty dept. He just uses socks more now to create those threads. Not that there weren't already plenty of reasons to suspect this ridiculous sock as coming from Snit but this thread shows that he's slipping in this respect: https://groups.google.com/forum/#!original/comp.os.linux.advocacy/cTXTtY57SjM/n9mXLZpIVXoJ I was being given GPG info and help by owl and we were both pretty much ignoring Snit all the way through. So who appears, who hadn't posted in a couple of days and then only posted to that thread on that day after Snit got tired of being ignored? -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVQ7iBAAoJEC03b6bOr/+dy+oQAM9++szzdDB6V8/Sdc4b2Yyh 8MmaCOi3l1OgD5lzRTXo1Uf5uNUVV7v5IMPVxepyuGzp1Bzmoo5z53eOXo+aRYiS i88RxYdZ9BtVIMu9YAbWn4cA4zco/LWlMyjXl454iYDkjNYr2gK6lrJdtnVLd+cO +KAxpZx5Pb14ADu2xWO0MwEXEv8BLfcBZeXwImlUBTEqVopGi9D9Wb0MY8ZI7Y2Q KKN/922K3FgXFcajy4/ms+kDJLrkziVXtRmCrRnNne1UqBdZA2dK68cnbhMOpWef qM6IivdLmVVFVUinY3KZDzb4HK+NMQaKoRNthPGaYcXYhZ/d6SIDJIqfJBEWpqLj dBM7V4u+4e2lOHyZjXDocbqdXpUMt4iemvWhWdFF3Hfaph2axCv1MXXdzXWbtten UdiwjIshGgn3UrHm6+SDaTKiwsUO0cDOF2k2f/qmd0Hq+KWzfuNWvq+bwl+BzXsR cldN67X+5odUyWP9ZP0mFjAqtXQVIGNc30uexrFuj4/RQ5KByhSvjA8jvGtWlGvU 7sRJL9WUx7uDcoRdDwG1U71qesKu5wSlcEA+RX5G1PnSjKx8wZs6RNM5eLSmpW/N /yGXzy5GKBgC3jjkuNktdzA3jq8Jhn8FKKcZi9s3vFT52FNqkEL0yd099wrVJSRQ NQK+zVtGRZz2Ds4oN0VK =6BdZ -----END PGP SIGNATURE----- - Live on Kickstarter http://www.5z8.info/how-to-build-a-bomb_h2o1be_peepshow https://www.youtube.com/watch?v=IhOfBmWwCVY https://youtu.be/TETJEkaUoY4 Jonas Eklundh Communication AB
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-03 19:50 +0100 |
| Message-ID | <LRIGC.135498$sc1.3990@fx09.am4> |
| In reply to | #130096 |
On 03/05/2018 19:02, Thiago Adams wrote: > On Thursday, May 3, 2018 at 9:57:45 AM UTC-3, Bart wrote: >> So I think persuading people to move from make (people for whom it >> happens to work), will be a big problem. > > Yes, before the standardization of #dir, #source .. they could be translated > to another tool Cmake maybe? There will be opposition. For example, there may be a project where the C code doesn't exist. It has to be generated for a fresh build. And that may require running arbitrary programs. This would be the problem in building such things into the C compiler. Because then you have a new way of controlling building of sources, but you will still need a way of doing everything else. If people need both, then they will stick with the one that already exists. (This wouldn't bother me greatly, but then I don't believe in trying to automate absolutely everything involved in building an application.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2018-05-03 13:37 -0700 |
| Message-ID | <cbda52b0-df2f-4e58-a84f-ff1270d6b390@googlegroups.com> |
| In reply to | #130099 |
On Thursday, May 3, 2018 at 3:50:31 PM UTC-3, Bart wrote: > On 03/05/2018 19:02, Thiago Adams wrote: > > On Thursday, May 3, 2018 at 9:57:45 AM UTC-3, Bart wrote: > > >> So I think persuading people to move from make (people for whom it > >> happens to work), will be a big problem. > > > > Yes, before the standardization of #dir, #source .. they could be translated > > to another tool Cmake maybe? > > There will be opposition. > > For example, there may be a project where the C code doesn't exist. It > has to be generated for a fresh build. And that may require running > arbitrary programs. > > This would be the problem in building such things into the C compiler. > Because then you have a new way of controlling building of sources, but > you will still need a way of doing everything else. If people need both, > then they will stick with the one that already exists. > > (This wouldn't bother me greatly, but then I don't believe in trying to > automate absolutely everything involved in building an application.) > > I think the logical concept of this program is made from file1.c file2.c.. for this configuration is also useful for other programs like static analysis. The way it is today,each program in the world must define what sources are part of the program in their own way making then incompatible with each other. I agree that the build scripts requires more steps like sign etc.. and this still dependent on platforms, so tools like cmake and the old bat files will not disappear, but they can use some standard way to say (at least) which files are used for the configuration, where to find the header files and libraries in a standard way.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2018-05-03 13:44 -0700 |
| Message-ID | <aee9b9de-3ed5-4a21-85fe-dedae2d3eb17@googlegroups.com> |
| In reply to | #130107 |
On Thursday, May 3, 2018 at 5:37:46 PM UTC-3, Thiago Adams wrote: > On Thursday, May 3, 2018 at 3:50:31 PM UTC-3, Bart wrote: > > On 03/05/2018 19:02, Thiago Adams wrote: > > > On Thursday, May 3, 2018 at 9:57:45 AM UTC-3, Bart wrote: > > > > >> So I think persuading people to move from make (people for whom it > > >> happens to work), will be a big problem. > > > > > > Yes, before the standardization of #dir, #source .. they could be translated > > > to another tool Cmake maybe? > > > > There will be opposition. > > > > For example, there may be a project where the C code doesn't exist. It > > has to be generated for a fresh build. And that may require running > > arbitrary programs. > > > > This would be the problem in building such things into the C compiler. > > Because then you have a new way of controlling building of sources, but > > you will still need a way of doing everything else. If people need both, > > then they will stick with the one that already exists. > > > > (This wouldn't bother me greatly, but then I don't believe in trying to > > automate absolutely everything involved in building an application.) > > > > > I think the logical concept of this program is made > from file1.c file2.c.. for this configuration is also > useful for other programs like static analysis. > The way it is today,each program in the world must define > what sources are part of the program in their own way making > then incompatible with each other. > > I agree that the build scripts requires more steps like sign etc.. > and this still dependent on platforms, so tools like cmake and the > old bat files will not disappear, but they can use some standard > way to say (at least) which files are used for the configuration, > where to find the header files and libraries in a standard way. refactoring tools also could use this configuration. "Programmer: Change the name of this function..." "Refactoring tools: where?" "Programmer: Check my program." "Static analysis" where did you put the header files? "What files should I look at?" "Programmer: Please generate the amalgamation of this lib" "Tool: which files should I include? The logical parts (c files) are described in a way everyone can understand.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2018-05-11 10:25 -0700 |
| Message-ID | <7f25e184-9424-45ca-9a92-f48023df42a5@googlegroups.com> |
| In reply to | #130108 |
On Thursday, May 3, 2018 at 5:44:56 PM UTC-3, Thiago Adams wrote: > On Thursday, May 3, 2018 at 5:37:46 PM UTC-3, Thiago Adams wrote: > > On Thursday, May 3, 2018 at 3:50:31 PM UTC-3, Bart wrote: > > > On 03/05/2018 19:02, Thiago Adams wrote: > > > > On Thursday, May 3, 2018 at 9:57:45 AM UTC-3, Bart wrote: > > > > > > >> So I think persuading people to move from make (people for whom it > > > >> happens to work), will be a big problem. > > > > > > > > Yes, before the standardization of #dir, #source .. they could be translated > > > > to another tool Cmake maybe? > > > > > > There will be opposition. > > > > > > For example, there may be a project where the C code doesn't exist. It > > > has to be generated for a fresh build. And that may require running > > > arbitrary programs. > > > > > > This would be the problem in building such things into the C compiler. > > > Because then you have a new way of controlling building of sources, but > > > you will still need a way of doing everything else. If people need both, > > > then they will stick with the one that already exists. > > > > > > (This wouldn't bother me greatly, but then I don't believe in trying to > > > automate absolutely everything involved in building an application.) > > > > > > > > I think the logical concept of this program is made > > from file1.c file2.c.. for this configuration is also > > useful for other programs like static analysis. > > The way it is today,each program in the world must define > > what sources are part of the program in their own way making > > then incompatible with each other. > > > > I agree that the build scripts requires more steps like sign etc.. > > and this still dependent on platforms, so tools like cmake and the > > old bat files will not disappear, but they can use some standard > > way to say (at least) which files are used for the configuration, > > where to find the header files and libraries in a standard way. > > refactoring tools also could use this configuration. > > "Programmer: Change the name of this function..." > "Refactoring tools: where?" > > "Programmer: Check my program." > "Static analysis" where did you put the header files? "What files should I look at?" > > "Programmer: Please generate the amalgamation of this lib" > "Tool: which files should I include? > > The logical parts (c files) are described in a way everyone can understand. As I was going to implement #source, some details become clear. There is no compilation, or imperative commands on build.c. Parser is like preprocessor and the final result after parsing is the internal state of the pre-processor. Sample: --- #define X 1 #source "file.h", "file.c" #ifdef WIN #source "somefile.h" #endif --- The final result is a list of sources , include dirs, lib dirs, and macro definitions that could represent the compiler command line arguments. header files are included just for information, they are not used in compiler command line. So, in case I put #source in some file that is not "build.c" the only effect is add to the preprocessor internal state the "source" info as it was a #define not used.
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-04-26 07:01 -0700 |
| Message-ID | <de7378ad-3626-4153-8e53-33a33f5fb9fe@googlegroups.com> |
| In reply to | #129779 |
On Thursday, April 26, 2018 at 3:45:15 AM UTC-7, Ben Bacarisse wrote: > bartc <bc@freeuk.com> writes: > > > On 25/04/2018 23:15, Ben Bacarisse wrote: > >> bartc <bc@freeuk.com> writes: > > > >>> It shows that it likes to be compiled with gcc. > >> > >> I think you missed the conditional (and you certainly ignored the > >> question). Given that the project uses a configuration/build system > >> (which you chose not to use), > > > > I didn't choose not to. I just can't because I don't know how, and > > when I've tried in the past, the results were hit and miss, usually > > miss, so now I don't even bother. > > Ah, I see. That means you have no idea what the build system might > bring to the party, and thus no idea what your numbers show. For all > you know the files you took a copy of may include complete or partial > configuration for one or other compiler, yes? > > >> Are any of these C compilers in default mode? The ones I know are not, > >> but I don't know them all. And for those that are, what version of C do > >> they compile? > > > > If you run any of those compilers with the name of a C file, they will > > compile that file. I don't think specifying the C version to be > > compiled would fix any of the errors I was seeing. > > I was commenting on the incorrect statement that you cut. (It's your > style to remove text with out any indication and you prefer me to do > that in my replies -- which I have done -- but it does not add to the > clarity of the discussion.) > > > Here's one such error: > > The errors you get on an un-configured or partially configured source > are not interesting (well, not to me, you seem to be interested in > them). In particular they don't help answer the questions I asked. > > > Just as a reminder of how it should be done IMO; pcc64.c > > Can you link to this file? It would be interesting so see just how much > simpler this program is than the one you posted about. > > > is a > > byte-code interpreter expressed as C code (about 1/4 the line count of > > the src\lib .c and .h files); pasted from actual output with no > > editing other than the indents: > > > > c:\cx>bcc pcc64 > > BCC Compiling pcc64.c to pcc64.asm > > > > c:\cx>mxa pcc64 > > Assembling/linking pcc64.asm... to pcc64.exe > > > > c:\cx>pcc64 hello > > Hello, World! > > > > No hassle; no fuss; IT JUST WORKS. > > It doesn't work for me. > > >>>>> The one problem file for gcc was a missing header that I couldn't find > >>>>> anywhere. > >>>> > >>>> Why do you want to keep it secret? > >>> > >>> Keep what a secret? > >> > >> The missing header file. > > > > It's xcb/xcb.h. There is no xcb directory anywhere in the project. > > Indeed. Why did you think there would be? > > -- > Ben. The one skill Donny Karcie learned fully is to attempt to humiliate Paul F. Riddle (https://www.facebook.com/drbud.greengenes) into back peddling and if that doesn't work, shout him down or dishonesty change the assertion. I quoted specific examples of Donny Karcie twisting Paul F. Riddle (https://www.facebook.com/drbud.greengenes)'s words, stating quotable lies, etc. His response: to claim I am Donny Karcie. Lots of trolls are babbling about the GNU/Linux "desktop" as if they think it literally is something we would want. -- Do not click this link! https://youtu.be/UkAyrfOZaXc https://youtu.be/Z5wo5aE7MUk Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2018-04-26 14:51 +0200 |
| Subject | Re: Clearly everyone else likes to do things the hard way |
| Message-ID | <pbsi18$ikr$1@dont-email.me> |
| In reply to | #129760 |
On 26/04/2018 03:02, bartc wrote: > Clearly everyone else likes to do things the hard way. Reminds me of an old joke. A guy is driving down highway 99, with music playing on the radio. The music stops for an important news flash: "Be careful, a lunatic is driving the wrong way on highway 99." And the guy screams at the radio: "It's not just one lunatic, it's everyone!"
[toc] | [prev] | [next] | [standalone]
| From | mark.bluemel@gmail.com |
|---|---|
| Date | 2018-04-26 07:09 -0700 |
| Subject | Re: Clearly everyone else likes to do things the hard way |
| Message-ID | <4c9f7cf8-1dbb-47cb-a827-9b1eb81c2c8a@googlegroups.com> |
| In reply to | #129784 |
On Thursday, 26 April 2018 13:52:03 UTC+1, Noob wrote: > On 26/04/2018 03:02, bartc wrote: > > > Clearly everyone else likes to do things the hard way. > > Reminds me of an old joke. > > A guy is driving down highway 99, with music playing on the radio. > The music stops for an important news flash: > "Be careful, a lunatic is driving the wrong way on highway 99." > And the guy screams at the radio: > "It's not just one lunatic, it's everyone!" :-) Bart in a nutshell.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2018-04-26 17:05 +0000 |
| Subject | Re: Clearly everyone else likes to do things the hard way |
| Message-ID | <pbt0su$q6k$1@news.xmission.com> |
| In reply to | #129788 |
In article <4c9f7cf8-1dbb-47cb-a827-9b1eb81c2c8a@googlegroups.com>, <mark.bluemel@gmail.com> wrote: >On Thursday, 26 April 2018 13:52:03 UTC+1, Noob wrote: >> On 26/04/2018 03:02, bartc wrote: >> >> > Clearly everyone else likes to do things the hard way. >> >> Reminds me of an old joke. >> >> A guy is driving down highway 99, with music playing on the radio. >> The music stops for an important news flash: >> "Be careful, a lunatic is driving the wrong way on highway 99." >> And the guy screams at the radio: >> "It's not just one lunatic, it's everyone!" > >:-) Bart in a nutshell. Quite so. Bart is clearly trolling - and effectively so, since people keep on responding to him. Or, looked at another way, Bart has a clear position, which is that C code should "just work" - that is, compile via "cc *.c" - and that build systems are unholy distractions. However, the facts are not in line with Bart's position; i.e., C is many things, but a "just works" language it is not. There are other languages that "just work", Turbo Pascal being the best example that comes to mind at the moment. -- Faith doesn't give you the answers; it just stops you from asking the questions.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-26 18:38 +0100 |
| Subject | Re: Clearly everyone else likes to do things the hard way |
| Message-ID | <z8oEC.148604$LD3.52921@fx18.am4> |
| In reply to | #129805 |
On 26/04/2018 18:05, Kenny McCormack wrote: > In article <4c9f7cf8-1dbb-47cb-a827-9b1eb81c2c8a@googlegroups.com>, > Or, looked at another way, Bart has a clear position, which is that C code > should "just work" - that is, compile via "cc *.c" - and that build > systems are unholy distractions. However, the facts are not in line with > Bart's position; i.e., C is many things, but a "just works" language it is > not. It can be that language but people don't make the effort. Do you see any of my programs with 20,000 or 30,000-line configure files that will only work on Unix, and that expect to be compiled only with gcc? Some larger projects will be more complicated, or the build may also take on the role of installing the various file of an application, but at present that complication is present even when wholly unwarranted. All the projects I've been working on the last few years, that could be represented as C, have each been available as a single C source file that was as simple to build as hello.c. People also don't understand the difference between a build system run hundreds of times a day while developing an unfinished program, and one that is merely needed to build a finished, working application. > should "just work" - that is, compile via "cc *.c" And why not? -- bartc
[toc] | [prev] | [next] | [standalone]
| From | 1alvinalbrecht1@gmail.com |
|---|---|
| Date | 2018-04-26 11:34 -0700 |
| Subject | Re: Clearly everyone else likes to do things the hard way |
| Message-ID | <487f17fe-1347-435b-a9ea-618690b4686a@googlegroups.com> |
| In reply to | #129811 |
On Thursday, April 26, 2018 at 11:38:50 AM UTC-6, Bart wrote: > > should "just work" - that is, compile via "cc *.c" > And why not? Because systems are not homogeneous. C targets everything from 8-bit processors to 64-bit with platforms ranging from essentially nothing to stuff that includes everything from the kitchen sink to the moon. Every such system is going to have platform-specific features, libraries and hardware. The C language cannot and must not define every single nook and cranny of every system produced or to be produced in the future. What it does is define a core language that these platforms can extend in an implementation defined way. So we have C used as the systems language in unix and linux. But these systems do not confine themselves to just the facilities of the standard library - they define an entire additional set of library facilities that's attempted to be standardized under posix. Because the core c library is insufficient for real systems. We have C used in windows. Microsoft fails to implement the C standard completely so you have to keep that in mind when writing for Windows. Windows, of course, supplies a Win32 API which is not the same as x or posix. So programming for windows is not the same as programming for linux. But what if you wanted to write a program that could be compiled for both windows and linux (or even just different flavours of unix/linux)? You'd have to write code that abstracted a common set of non-standard functions that you wanted to use, you'd have to accommodate missing functionality or weaknesses in one compiler or another used for the different targets, etc. This is when you end up with configure scripts for large projects. Having one homogeneous c source for everything is not going to work except for simple projects confined to the command line. Consolidating everything into a single .c file is not going to work either except for small projects. You're defeating how C programmers deal with complexity, namely the traditional header/source separation used to publish information about the "public" portion of apis and the logical separation of independent modules into different directories containing c source. This also ignores the fact that the capability c tools vary widely from the 8-bit case to the 64-bit case. Some of these tools are not able to prune out dead code from large consolidated files but they can when files are separated into pieces. I already hear the chorus "use a better tool". But such tools don't always exist and that's true (for other issues) even on powerful modern platforms.
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web