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

Groups > comp.lang.c > #129717 > unrolled thread

gcc_centric C code

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

Contents

  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 5 of 6 — ← Prev page 1 2 3 4 [5] 6  Next page →

#129819 — Re: Clearly everyone else likes to do things the hard way

On 26/04/2018 19:34, 1alvinalbrecht1@gmail.com wrote:
> 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?

> 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.

Is it going to be that much bigger a deal that typing one of these lines:

   gcc prog_main.c prog_windows.c       # windows target
   gcc prog_main.c prog_linux.c         # linux target

where the second file contains OS-specific stuff?

> This is when you end up with configure scripts for large projects.

I haven't seen evidence of the need for this yet. Perhaps people who 
write such scripts get them mixed with what happens when you install an 
application?

My theory is that those who develop on Unix get into the habit of having 
to rely on dozens of utilities to do the simplest thing, and they so get 
into that mindset, that they think any other approach must be inferior.

Then, a 29,771-line configure script to build the gmp library (which is 
not even a command line app) would seem reasonable instead of utterly 
ridiculous (my entire C compiler is only 17,400 lines; how complicated 
can it possibly be to figure out which options should be passed to a C 
compiler to build the project?).

> Having one homogeneous c source for everything is not going to work except for simple projects confined to the command line.

I think all the projects I have tried to build, worked from the command 
line, and they STILL have these configure scripts! It's that mindset at 
work.

I have my own set of tools and my own ways of managing my source code, 
but I try not to inflict them on anyone else.

solidating 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,

You don't seem to understand the purpose of that consolidation. It is 
not intended to use that format for when developing the source code. It 
is only for distribution to allow people to build-from-source, when 
using prebuilt binaries is not suitable.

That the original source is scattered over 45 directories and uses 230 
header files in assorted locations, arranged so that only modified files 
need to be compiled, is for the benefit of the developer.

It is of no interest to the guy (or 100 guys) who just wants to download 
your program as source and somehow get to run it by building from scratch.

This seems to be understood when people convert hundreds of source files 
into a single executable file.

A single consolidated source file serves the same purpose, but one step 
back with more flexibility - you can compile to a choice of targets with 
a choice of compilers and a choice of options. There can also be options 
to be set at the top of the file, and compiled into the program.

But the main advantage is managing all the files needed to package it, 
distribute it, install it and build it becomes ludicrously simple.

You don't of course need to use exactly one file, but if the number was 
in single figures and they were all in the same place, it makes life 
simpler.

-- 
bartc

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

#129890 — Re: Clearly everyone else likes to do things the hard way

bartc <bc@freeuk.com> wrote:
> On 26/04/2018 19:34, 1alvinalbrecht1@gmail.com wrote:
>> 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?
> 
>> 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.
> 
> Is it going to be that much bigger a deal that typing one of these lines:
> 
>   gcc prog_main.c prog_windows.c       # windows target
>   gcc prog_main.c prog_linux.c         # linux target
> 
> where the second file contains OS-specific stuff?
> 
>> This is when you end up with configure scripts for large projects.
> 
> I haven't seen evidence of the need for this yet. Perhaps people who 
> write such scripts get them mixed with what happens when you install an 
> application?


A C / GTK project of mine was initially built with a Makefile of 173 lines;
a separate shell script was used to install the binaries and help files.
Once I had some idea of what I was trying to do I moved it to Autotools, and
ended up with three Makefile.am files of 77, 30, and 20 lines each.  The
77 line file would have been a lot shorter if I hadn't added some baroque
version update macros.  The relevant configure.ac file was 135 lines, and
the resulting configure file 7459 lines.  But I've never needed to look
at the configure file, and I wouldn't understand it if I did.

Among the advantages of the Autotools setup, bearing in mind that the software
runs only on versions of Linux, are that it checks for the necessary libraries,
documents the various build options and allows the user to choose between them,
allows for different installation root directories, and packages the files
so that "tar xf whatever; configure && make && make install" is all that is
needed to build and install the project.

I've used the software for eight years now, and installed it on different
machines every year or so.  I really wouldn't want to go back to checking
header and library availability by hand, and building with a Makefile and
shell scripts.

YMMV - Will

-- 
Every word of [this] is true. Except the nouns and the verbs, and most of
the adjectives. But the conjunctions? They have the gritty tang of veracity.
   John Scalzi

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

#129898 — Re: Clearly everyone else likes to do things the hard way

On 27/04/2018 19:23, C W Rose wrote:
> bartc <bc@freeuk.com> wrote:
>> On 26/04/2018 19:34, 1alvinalbrecht1@gmail.com wrote:

>>> This is when you end up with configure scripts for large projects.
>>
>> I haven't seen evidence of the need for this yet. Perhaps people who
>> write such scripts get them mixed with what happens when you install an
>> application?
> 
> 
> A C / GTK project of mine was initially built with a Makefile of 173 lines;
> a separate shell script was used to install the binaries and help files.
> Once I had some idea of what I was trying to do I moved it to Autotools, and
> ended up with three Makefile.am files of 77, 30, and 20 lines each.  The
> 77 line file would have been a lot shorter if I hadn't added some baroque
> version update macros.  The relevant configure.ac file was 135 lines, and
> the resulting configure file 7459 lines.

That all sounded reasonable, until I noticed this figure. You've never 
been curious as to how 200 lines of make instructions ended up as 7500 
lines of gobbledygook that you admit you don't understand?

   But I've never needed to look
> at the configure file, and I wouldn't understand it if I did.

Effectively the build instructions for the project are written in a 
different language (possibly, several), with extra dependencies other 
than the 'C' compiler that is expected. Instructions that are hard to 
understand.

Imagine if, for some reason, someone (not necessarily you), has to build 
this by hand; where is the build information for a human to do those steps?

> Among the advantages of the Autotools setup, bearing in mind that the software
> runs only on versions of Linux, are that it checks for the necessary libraries,
> documents the various build options and allows the user to choose between them,
> allows for different installation root directories, and packages the files
> so that "tar xf whatever; configure && make && make install" is all that is
> needed to build and install the project.
> 
> I've used the software for eight years now, and installed it on different
> machines every year or so.  I really wouldn't want to go back to checking
> header and library availability by hand, and building with a Makefile and
> shell scripts.

(My last proper non-command-line application was a simple CAD program, 
and the project file from the last version of it (in early 2000s) is 
given below.

It's not written in C (except one module); uses external WinAPI and 
OpenGL libraries; and appears to use gcc to link it.

  "module" lines are source files to be compiled
  "link"   lines are external binary libraries
  "header" lines used to produce the main header file this language uses
           (as shown in second file below)
  "file"   lines are misc text files for browsing

This was used by my IDE and I believe the commands to build from scratch 
wer:

  "CH" create the main header
  "CA" compile all modules
  "L"  link to .exe
  "R"  run

(There are also 75 script files, steps for internationalisation, and 
resource files; installation was a totally separate matter done by other 
people and customised for their add-ons and data.)

You can see this is fairly straightforward, and if necessary the build 
can be done a file at a time using this information. (You do need to 
know how to compile .q files, in the same way you have to know how to 
compile hello.c).  And this was not even open source.

(The newer compilers I'm developing now have even simpler requirements 
and may not need a project file: just compile the lead module to produce 
an executable file for the whole program. The project file is to help 
browse through the source code.

Compare with the direction C make systems are going in, which is for 
even greater complexity.))

---------------------------
	run .\sc

	module mplc.q
	module gltest.q
	module dxscan.q
	module readdxf.q
	module mpci.q
	module mpcilib.q
	module gs.q
	module start.q

	module memory.q
	module gx.q
	module maths.q
	module messages.q

	module dwg.q
	module text.q
	module cadlib.q
	module hide.q
	module shade.q
	module mbitmaps.q
	module dsgdi.q

	module bitmaps.q
	module oldlib.q
	module \m\clib.c
	module \m\qlib.q

	link \\mingw\\lib\\libkernel32.a
	link \\mingw\\lib\\libuser32.a
	link \\mingw\\lib\\libgdi32.a
	link \\mingw\\lib\\libwinspool.a
	link \\mingw\\lib\\libcomctl32.a
	link \\mingw\\lib\\libcomdlg32.a
	link \\mingw\\lib\\libopengl32.a
	link \\mingw\\lib\\libglu32.a

	header \m\WINHDR.Q
	header \m\QLIBHDR.Q

	header SCRECORDS.Q
	header SCPROCS.Q
	header SCCONSTS.Q
	header SCVARS.Q

	header GLHDR.Q
	header DXHDR.Q

	file windows.h
	file mpl6.mpl

-------------------------------

Single header file produced by "CH" command for the above project:

!Auto-header file generated by DD for sc.pro
include "\\m\\WINHDR.Q"
include "\\m\\QLIBHDR.Q"
include "SCRECORDS.Q"
include "SCPROCS.Q"
include "SCCONSTS.Q"
include "SCVARS.Q"
include "GLHDR.Q"
include "DXHDR.Q"


-- 
bartc

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

#129906 — Re: Clearly everyone else likes to do things the hard way

On Saturday, April 28, 2018 at 6:34:25 AM UTC-7, Bart wrote:
> On 27/04/2018 19:23, C W Rose wrote:
> > bartc <bc@freeuk.com> wrote:
> >> On 26/04/2018 19:34, 1alvinalbrecht1@gmail.com wrote:
> 
> >>> This is when you end up with configure scripts for large projects.
> >>
> >> I haven't seen evidence of the need for this yet. Perhaps people who
> >> write such scripts get them mixed with what happens when you install an
> >> application?
> > 
> > 
> > A C / GTK project of mine was initially built with a Makefile of 173 lines;
> > a separate shell script was used to install the binaries and help files.
> > Once I had some idea of what I was trying to do I moved it to Autotools, and
> > ended up with three Makefile.am files of 77, 30, and 20 lines each.  The
> > 77 line file would have been a lot shorter if I hadn't added some baroque
> > version update macros.  The relevant configure.ac file was 135 lines, and
> > the resulting configure file 7459 lines.
> 
> That all sounded reasonable, until I noticed this figure. You've never 
> been curious as to how 200 lines of make instructions ended up as 7500 
> lines of gobbledygook that you admit you don't understand?
> 
>    But I've never needed to look
> > at the configure file, and I wouldn't understand it if I did.
> 
> Effectively the build instructions for the project are written in a 
> different language (possibly, several), with extra dependencies other 
> than the 'C' compiler that is expected. Instructions that are hard to 
> understand.
> 
> Imagine if, for some reason, someone (not necessarily you), has to build 
> this by hand; where is the build information for a human to do those steps?
> 
> > Among the advantages of the Autotools setup, bearing in mind that the software
> > runs only on versions of Linux, are that it checks for the necessary libraries,
> > documents the various build options and allows the user to choose between them,
> > allows for different installation root directories, and packages the files
> > so that "tar xf whatever; configure && make && make install" is all that is
> > needed to build and install the project.
> > 
> > I've used the software for eight years now, and installed it on different
> > machines every year or so.  I really wouldn't want to go back to checking
> > header and library availability by hand, and building with a Makefile and
> > shell scripts.
> 
> (My last proper non-command-line application was a simple CAD program, 
> and the project file from the last version of it (in early 2000s) is 
> given below.
> 
> It's not written in C (except one module); uses external WinAPI and 
> OpenGL libraries; and appears to use gcc to link it.
> 
>   "module" lines are source files to be compiled
>   "link"   lines are external binary libraries
>   "header" lines used to produce the main header file this language uses
>            (as shown in second file below)
>   "file"   lines are misc text files for browsing
> 
> This was used by my IDE and I believe the commands to build from scratch 
> wer:
> 
>   "CH" create the main header
>   "CA" compile all modules
>   "L"  link to .exe
>   "R"  run
> 
> (There are also 75 script files, steps for internationalisation, and 
> resource files; installation was a totally separate matter done by other 
> people and customised for their add-ons and data.)
> 
> You can see this is fairly straightforward, and if necessary the build 
> can be done a file at a time using this information. (You do need to 
> know how to compile .q files, in the same way you have to know how to 
> compile hello.c).  And this was not even open source.
> 
> (The newer compilers I'm developing now have even simpler requirements 
> and may not need a project file: just compile the lead module to produce 
> an executable file for the whole program. The project file is to help 
> browse through the source code.
> 
> Compare with the direction C make systems are going in, which is for 
> even greater complexity.))
> 
> ---------------------------
> 	run .\sc
> 
> 	module mplc.q
> 	module gltest.q
> 	module dxscan.q
> 	module readdxf.q
> 	module mpci.q
> 	module mpcilib.q
> 	module gs.q
> 	module start.q
> 
> 	module memory.q
> 	module gx.q
> 	module maths.q
> 	module messages.q
> 
> 	module dwg.q
> 	module text.q
> 	module cadlib.q
> 	module hide.q
> 	module shade.q
> 	module mbitmaps.q
> 	module dsgdi.q
> 
> 	module bitmaps.q
> 	module oldlib.q
> 	module \m\clib.c
> 	module \m\qlib.q
> 
> 	link \\mingw\\lib\\libkernel32.a
> 	link \\mingw\\lib\\libuser32.a
> 	link \\mingw\\lib\\libgdi32.a
> 	link \\mingw\\lib\\libwinspool.a
> 	link \\mingw\\lib\\libcomctl32.a
> 	link \\mingw\\lib\\libcomdlg32.a
> 	link \\mingw\\lib\\libopengl32.a
> 	link \\mingw\\lib\\libglu32.a
> 
> 	header \m\WINHDR.Q
> 	header \m\QLIBHDR.Q
> 
> 	header SCRECORDS.Q
> 	header SCPROCS.Q
> 	header SCCONSTS.Q
> 	header SCVARS.Q
> 
> 	header GLHDR.Q
> 	header DXHDR.Q
> 
> 	file windows.h
> 	file mpl6.mpl
> 
> -------------------------------
> 
> Single header file produced by "CH" command for the above project:
> 
> !Auto-header file generated by DD for sc.pro
> include "\\m\\WINHDR.Q"
> include "\\m\\QLIBHDR.Q"
> include "SCRECORDS.Q"
> include "SCPROCS.Q"
> include "SCCONSTS.Q"
> include "SCVARS.Q"
> include "GLHDR.Q"
> include "DXHDR.Q"
> 
> 
> -- 
> bartc



Well... like I said, I know the flooder is Staci M. Elliot, who is a programmer but I don't know if it could be used to get by Google's spam filters. Vennie Bowden, Realtor's earliest statement stands proper and correct. My uptime is almost twenty-seven weeks and Vennie Bowden, Realtor is a better man than you will even be! 

Ha, ha! 

Frankly I do not really think you understand. 

Who are you even blubbering to? 

-- 
Eight things to never feed your dog
http://www.5z8.info/myspace-of-sex_q7q7zl_instant-purchase
https://youtu.be/iztSc_msHuo
Jonas Eklundh Communication

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

#129975 — Re: Clearly everyone else likes to do things the hard way

On Saturday, April 28, 2018 at 8:34:25 AM UTC-5, Bart wrote:
> Effectively the build instructions for the project are written in a 
> different language (possibly, several), with extra dependencies other 
> than the 'C' compiler that is expected. Instructions that are hard to 
> understand.

A very useful trait of the vast majority of hosted C implementations is
that a "text" file written by the implementation will use the same format
as a source file.  Thus, it should be possible to distribute a project as
one files--myThing.c.  To build the project, simply compile myThing.c and
run the executable in the same directory as the source; it can then give a
message with whatever command-line options it needs to control
configuration, and when it's invoked with those options it can then use
information in myThing.c [perhaps embedded within a giant comment] to
construct a source file that can be built to produce the final application,
and output any special requirements for building that file.

Although this would be far from the ideal format in cases where someone
needs to make changes to the program, especially if those changes need to
be integrated back into the main branch, it would satisfy the far more
common usage case where someone simply wants to use the program on a
generic system for which it has not previously been built.  The program
that generates the main source file from the .c file could be very
simple [mostly outputting the contents of the comment verbatim, but
skipping certain parts based upon invocation options] or it could be a much
more complicated program for some other language that translates code in
the .txt file from some other language into C, or it could do just about
any platform-neutral task that might otherwise require use of non-standard
utilities.  The key point would be that use of the program should not
require anything beyond a C implementation that generates programs that do
file I/O in via means compatible with the compiler itself.

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

#129978 — Re: Clearly everyone else likes to do things the hard way

On 30/04/2018 18:16, supercat@casperkitty.com wrote:
> On Saturday, April 28, 2018 at 8:34:25 AM UTC-5, Bart wrote:
>> Effectively the build instructions for the project are written in a
>> different language (possibly, several), with extra dependencies other
>> than the 'C' compiler that is expected. Instructions that are hard to
>> understand.
> 
> A very useful trait of the vast majority of hosted C implementations is
> that a "text" file written by the implementation will use the same format
> as a source file.  Thus, it should be possible to distribute a project as
> one files--myThing.c.  To build the project, simply compile myThing.c and
> run the executable in the same directory as the source; it can then give a
> message with whatever command-line options it needs to control
> configuration, and when it's invoked with those options it can then use
> information in myThing.c [perhaps embedded within a giant comment] to
> construct a source file that can be built to produce the final application,
> and output any special requirements for building that file.

I've just tried something like that (not C code):

     import clib
     import mlib

     proc start=
         ref char sourcecode = strinclude "bcc64.c"

         writefile("prog.c", sourcecode, strlen(sourcecode))

         if system("gcc prog.c -oprog.exe") then
             println "Build error"
         else
             println "Successfully compiled prog.c to prog.exe"
         fi
     end

This runs and produces prog.exe (which also runs). But in this original 
form, there are two source files: this one, and bcc64.c which resides on 
disk. Translated to C however, it is just one file (of size 0.5MB), 
which includes this line:

static char * sourcecode="/* MCC Experimental C Compiler\r\n\r\n .... "

which is 480,000 characters long (somewhat longer than the original 
because of the escape codes).

Compiling that C version and running it also works. Since this is a C 
program, and a small one apart from the string, it can be written in 
portable code (another than the need to deal with very long strings), 
and can interrogate the host system for the most appropriate C compiler 
settings. And then build the real program.



> Although this would be far from the ideal format in cases where someone
> needs to make changes to the program, especially if those changes need to
> be integrated back into the main branch, it would satisfy the far more
> common usage case where someone simply wants to use the program on a
> generic system for which it has not previously been built.  The program
> that generates the main source file from the .c file could be very
> simple [mostly outputting the contents of the comment verbatim, but
> skipping certain parts based upon invocation options] or it could be a much
> more complicated program for some other language that translates code in
> the .txt file from some other language into C, or it could do just about
> any platform-neutral task that might otherwise require use of non-standard
> utilities.  The key point would be that use of the program should not
> require anything beyond a C implementation that generates programs that do
> file I/O in via means compatible with the compiler itself.

If I'm on the right lines then that's what the example above demonstrates.

-- 
bartc

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

#129979 — Re: Clearly everyone else likes to do things the hard way

On Monday, April 30, 2018 at 1:41:25 PM UTC-5, Bart wrote:
> Translated to C however, it is just one file (of size 0.5MB), 
> which includes this line:
> 
> static char * sourcecode="/* MCC Experimental C Compiler\r\n\r\n .... "
> 
> which is 480,000 characters long (somewhat longer than the original 
> because of the escape codes).
> 
> Compiling that C version and running it also works. Since this is a C 
> program, and a small one apart from the string, it can be written in 
> portable code (another than the need to deal with very long strings), 
> and can interrogate the host system for the most appropriate C compiler 
> settings. And then build the real program.

Using a string literal would require that the entire program be capable of
fitting in memory.  Depending upon the size of the program and the target
platform, that may or may not be a problem.  I would expect that most
implementations would be capable of handling an almost-arbitrarily-large
comment within any source file whose total size was less than 2GiB, even
if they couldn't handle strings anywhere near that big.  Using a separate
data file rather than a comment might improve efficiently a tiny bit (by
eliminating the need to have a compiler skip over a giant comment) but
would make it necessary to keep the program and its data file "in sync".

BTW, I would think compiler performance in many of situations could be
improved if the Standard were to define a directive:

#pragma STDC_SKIP_REMAINDER

which, at a compiler's option, could either do nothing or behave as though
the balance of the source file contained nothing except sufficient #endif
directives to balance out any preceding #if directives.  Existing compilers
wouldn't have to do anything to be compatible with such a directive, but
replacing

    #if !defined(FOO_H)
    #define FOO_H
    ...
    #endif

with

    #if defined(FOO_H)
    #pragma STDC_SKIP_REMAINDER
    #else
    #define FOO_H
    ...
    #endif

could improve compilation performance in cases where foo.h gets included
from multiple places while processing a translation unit, since a compiler
wouldn't have to read through the #else block to find the #endif.

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

#129981 — Re: Clearly everyone else likes to do things the hard way

supercat@casperkitty.com writes:
>On Monday, April 30, 2018 at 1:41:25 PM UTC-5, Bart wrote:
>> Translated to C however, it is just one file (of size 0.5MB), 
>> which includes this line:
>> 
>> static char * sourcecode="/* MCC Experimental C Compiler\r\n\r\n .... "
>> 
>> which is 480,000 characters long (somewhat longer than the original 
>> because of the escape codes).
>> 
>> Compiling that C version and running it also works. Since this is a C 
>> program, and a small one apart from the string, it can be written in 
>> portable code (another than the need to deal with very long strings), 
>> and can interrogate the host system for the most appropriate C compiler 
>> settings. And then build the real program.
>
>Using a string literal would require that the entire program be capable of
>fitting in memory.  Depending upon the size of the program and the target
>platform, that may or may not be a problem.  I would expect that most
>implementations would be capable of handling an almost-arbitrarily-large
>comment within any source file whose total size was less than 2GiB, even
>if they couldn't handle strings anywhere near that big.  Using a separate
>data file rather than a comment might improve efficiently a tiny bit (by
>eliminating the need to have a compiler skip over a giant comment) but
>would make it necessary to keep the program and its data file "in sync".
>
>BTW, I would think compiler performance in many of situations could be
>improved if the Standard were to define a directive:
>
>#pragma STDC_SKIP_REMAINDER
>
>which, at a compiler's option, could either do nothing or behave as though
>the balance of the source file contained nothing except sufficient #endif
>directives to balance out any preceding #if directives.  Existing compilers
>wouldn't have to do anything to be compatible with such a directive, but
>replacing
>
>    #if !defined(FOO_H)
>    #define FOO_H
>    ...
>    #endif
>
>with
>
>    #if defined(FOO_H)
>    #pragma STDC_SKIP_REMAINDER
>    #else
>    #define FOO_H
>    ...
>    #endif
>
>could improve compilation performance in cases where foo.h gets included
>from multiple places while processing a translation unit, since a compiler
>wouldn't have to read through the #else block to find the #endif.

Maybe in 1984.   Today it would be unnoticable.

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

#129980 — Re: Clearly everyone else likes to do things the hard way

bartc <bc@freeuk.com> writes:
>On 30/04/2018 18:16, supercat@casperkitty.com wrote:
>> On Saturday, April 28, 2018 at 8:34:25 AM UTC-5, Bart wrote:
>>> Effectively the build instructions for the project are written in a
>>> different language (possibly, several), with extra dependencies other
>>> than the 'C' compiler that is expected. Instructions that are hard to
>>> understand.
>> 
>> A very useful trait of the vast majority of hosted C implementations is
>> that a "text" file written by the implementation will use the same format
>> as a source file.  Thus, it should be possible to distribute a project as
>> one files--myThing.c.  To build the project, simply compile myThing.c and
>> run the executable in the same directory as the source; it can then give a
>> message with whatever command-line options it needs to control
>> configuration, and when it's invoked with those options it can then use
>> information in myThing.c [perhaps embedded within a giant comment] to
>> construct a source file that can be built to produce the final application,
>> and output any special requirements for building that file.
>
>I've just tried something like that (not C code):
>

     import clib
     import mlib

     proc start=
         ref char sourcecode = strinclude "bcc64.c"

         writefile("prog.c", sourcecode, strlen(sourcecode))

         if system("gcc prog.c -oprog.exe") then
             println "Build error"
         else
             println "Successfully compiled prog.c to prog.exe"
         fi
     end

>This runs and produces prog.exe (which also runs). But in this original 
>form, there are two source files: this one, and bcc64.c which resides on 
>disk. Translated to C however, it is just one file (of size 0.5MB), 
>which includes this line:

self-extracting shell script archives have been used to distribute
and build source code for over three decades (especially in the
early days of Usenet).

There are reasons that autotools, ugly as they may be,
have superceeded self-extracting shell archives (which unlike
Bart's example above, don't require an special language compiler to be
installed).

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

#129982 — Re: Clearly everyone else likes to do things the hard way

On 30/04/2018 20:12, Scott Lurndal wrote:
> bartc <bc@freeuk.com> writes:

>> This runs and produces prog.exe (which also runs). But in this original
>> form, there are two source files: this one, and bcc64.c which resides on
>> disk. Translated to C however, it is just one file (of size 0.5MB),
>> which includes this line:
> 
> self-extracting shell script archives have been used to distribute
> and build source code for over three decades (especially in the
> early days of Usenet).
> 
> There are reasons that autotools, ugly as they may be,
> have superceeded self-extracting shell archives (which unlike
> Bart's example above, don't require an special language compiler to be
> installed).

In the form of C for an application also in C, it means there is a 
dependency on just one language and one implementation of it.

The tool needed to turn a C source file into a string is something that 
is needed by whoever is creating the distribution, not by the person 
building the application. I used my language for the example because 
that feature is built-in and I could turn the result into C.

-- 
bartc

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

#129985 — Re: Clearly everyone else likes to do things the hard way

On Monday, April 30, 2018 at 11:41:25 AM UTC-7, Bart wrote:
> On 30/04/2018 18:16, supercat@casperkitty.com wrote:
> > On Saturday, April 28, 2018 at 8:34:25 AM UTC-5, Bart wrote:
> >> Effectively the build instructions for the project are written in a
> >> different language (possibly, several), with extra dependencies other
> >> than the 'C' compiler that is expected. Instructions that are hard to
> >> understand.
> > 
> > A very useful trait of the vast majority of hosted C implementations is
> > that a "text" file written by the implementation will use the same format
> > as a source file.  Thus, it should be possible to distribute a project as
> > one files--myThing.c.  To build the project, simply compile myThing.c and
> > run the executable in the same directory as the source; it can then give a
> > message with whatever command-line options it needs to control
> > configuration, and when it's invoked with those options it can then use
> > information in myThing.c [perhaps embedded within a giant comment] to
> > construct a source file that can be built to produce the final application,
> > and output any special requirements for building that file.
> 
> I've just tried something like that (not C code):
> 
>      import clib
>      import mlib
> 
>      proc start=
>          ref char sourcecode = strinclude "bcc64.c"
> 
>          writefile("prog.c", sourcecode, strlen(sourcecode))
> 
>          if system("gcc prog.c -oprog.exe") then
>              println "Build error"
>          else
>              println "Successfully compiled prog.c to prog.exe"
>          fi
>      end
> 
> This runs and produces prog.exe (which also runs). But in this original 
> form, there are two source files: this one, and bcc64.c which resides on 
> disk. Translated to C however, it is just one file (of size 0.5MB), 
> which includes this line:
> 
> static char * sourcecode="/* MCC Experimental C Compiler\r\n\r\n .... "
> 
> which is 480,000 characters long (somewhat longer than the original 
> because of the escape codes).
> 
> Compiling that C version and running it also works. Since this is a C 
> program, and a small one apart from the string, it can be written in 
> portable code (another than the need to deal with very long strings), 
> and can interrogate the host system for the most appropriate C compiler 
> settings. And then build the real program.
> 
> 
> 
> > Although this would be far from the ideal format in cases where someone
> > needs to make changes to the program, especially if those changes need to
> > be integrated back into the main branch, it would satisfy the far more
> > common usage case where someone simply wants to use the program on a
> > generic system for which it has not previously been built.  The program
> > that generates the main source file from the .c file could be very
> > simple [mostly outputting the contents of the comment verbatim, but
> > skipping certain parts based upon invocation options] or it could be a much
> > more complicated program for some other language that translates code in
> > the .txt file from some other language into C, or it could do just about
> > any platform-neutral task that might otherwise require use of non-standard
> > utilities.  The key point would be that use of the program should not
> > require anything beyond a C implementation that generates programs that do
> > file I/O in via means compatible with the compiler itself.
> 
> If I'm on the right lines then that's what the example above demonstrates.
> 
> -- 
> bartc



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Snit is not running from this forger, he's running from me.
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJV5iqVAAoJEC03b6bOr/+dmLoQAIdHYN1feyWJ/SVZdvG6QxAa
z8N7UmFjUAJUtwRzPEpDydU/beEoOGsa/M7MRHfOhRv4XJcQWjk6ouQfW0JyQFG9
rYQONKuvpypOTA4suPMHuRelgV8o5vsT6nsnkhu3A3Vl8JT8QeYvwNlDUtsuPo67
TtJ11dKv9WmtqqV0jspikxaegpb4z8/ipc12/rl6ecLu9xadA/zaWCXinfjKtCdK
sv1Y48I4mxhRzURDBf3ad/XteOCnYRum4IS4fP4WrMhjaOF/zrK2dSKtKdZ5BD6c
DU1wnP52A35i/ZH02EA60sDBS23YBogMTkx3UJ9RW9wxz/x5derTSyK12z8IRAYE
pypLNtDjIzuuebWu17TxVhYjrvy7E2VH5/7ElQmheMlQdAJmQG/GAXozseswBKnV
X+jzVigbsOEHsYWvJuP38g9o1wUPp0lENdQpzu3IohaG9X7wGHVz9cZ07he5ciCA
tXLtNYcF0/9zoiX2LALGEAOrKkW/APTKkk4FsvPXNf78kdGu9aWd/bygshzUPY9o
LnTVyDluUCSmFI70+FSXUy8pmWrgajv8hYqtlxCaxgQr8x1hnc/wnUSb2zPIfYJT
dzrKAlFJ5HFJf8llwjKNksAVoU/RQ6Q+Yg3RufvoYH2D8b1pk5rLj9C9svPkU18X
7DDD35qwaoj2vKsXG31G
=fwCb
-----END PGP SIGNATURE-----

--
One Smart Penny
https://groups.google.com/forum/#!topic/comp.lang.c/KDQrv8appR8
https://groups.google.com/forum/#!topic/comp.os.linux.development.apps/G2-ZXYAEyIM
https://youtu.be/TETJEkaUoY4
Jonas Eklundh Communication AB

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

#129813 — Re: Clearly everyone else likes to do things the hard way

Am 26.04.2018 um 19:05 schrieb Kenny McCormack:
> 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.
> 

There are C programs that "just work". However, mayn C programs are big
projects, and big projects (or even just small ones with dependencies)
tend to not "just work" no matter the language.

Philipp

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

#129765

On Wednesday, April 25, 2018 at 12:36:39 PM UTC-5, Bart wrote:
> On 25/04/2018 16:41, Ben Bacarisse wrote:
> > bartc <bc@freeuk.com> writes:
> > 
> >> I took one github C project
> > 
> > Which one?
> 
> I was reluctant to link to it as it was written by a poster here. But I 
> don't think I've said anything that doesn't apply to most open source 
> projects, so just google for for 'luser postscript'; I think it was the 
> second hit. The directory was src/lib.

As the luser in question, I feel obliged to point out that the Xpost
source code is heavily dependent upon the config.h file that is 
generated during the autotools configuration step. A lot of the macros
defined in that file are feature tests or checks for the presence of 
libraries. In particular, if xcb is not detected during configure, then
the xcb device does not get compiled. FWIW I'll append the config.h 
generated for cygwin which should give an idea of what macros it uses
and what sort of values they should have. (The jokes in the config.h
file are there to help navigate the heinous autotools files.)

That said, I do accept some of your critique. That ugly #ifdef block
from the first post in this thread is repeated needlessly in many files.
And there is quite a bit of clutter and many long, long functions that
want factoring. A lot of work has been recently done to clean this up
but it has not been propagated back to github yet.

There is a previous version of the project which has a much simpler
build that does not require autotools. It has a more limited feature
set overall and implements less of the PostScript standard, but it
has a few features that the latest version does not. Notably, since 
the older Xpost uses Cairo for graphics it also has a pdf output device.

http://web.archive.org/web/20160404161603/https://code.google.com/p/xpost/downloads/detail?name=xpost2g.zip&can=2&q=

PDF output without a library to do all the work is taking somewhat 
longer get going.




$ cat xpost/config.h
/* config.h.  Generated from config.h.in by configure.  */
/* config.h.in.  Generated from configure.ac by autoheader.  */

/* Define to one of `_getb67', `GETB67', `getb67' for Cray-2 and Cray-YMP
   systems. This function is required for `alloca.c' support on those systems.
   */
/* #undef CRAY_STACKSEG_END */

/* Define to 1 if using `alloca.c'. */
/* #undef C_ALLOCA */

/* Define to 1 if you have `alloca', as a function or macro. */
#define HAVE_ALLOCA 1

/* Define to 1 if you have <alloca.h> and it should be used (not on Ultrix).
   */
#define HAVE_ALLOCA_H 1

/* Define to 1 if you have the `buckets_of_erogenous_nym' function. */
/* #undef HAVE_BUCKETS_OF_EROGENOUS_NYM */

/* Define to 1 if you have the `buttox' function. */
/* #undef HAVE_BUTTOX */

/* Define to 1 if check unit testing library is available */
/* #undef HAVE_CHECK */

/* Define to 1 if you have the `dirname' function. */
#define HAVE_DIRNAME 1

/* Define to 1 if you have the <dlfcn.h> header file. */
#define HAVE_DLFCN_H 1

/* Define to 1 if Fontconfig is detected */
#define HAVE_FONTCONFIG 1

/* Define to 1 if Freetype is detected */
#define HAVE_FREETYPE 1

/* Define to 1 if getpagesize() is available */
/* #undef HAVE_GETPAGESIZE */

/* Define to 1 if you have the `gettimeofday' function. */
#define HAVE_GETTIMEOFDAY 1

/* Define to 1 if you have the <inttypes.h> header file. */
#define HAVE_INTTYPES_H 1

/* Define to 1 if you have the `Fridge' library (-lFridge). */
/* #undef HAVE_LIBFRIDGE */

/* Define to 1 if you have the <libgen.h> header file. */
#define HAVE_LIBGEN_H 1

/* Define to 1 if libjpeg is detected */
#define HAVE_LIBJPEG 1

/* Define to 1 if you have the `Kenny' library (-lKenny). */
/* #undef HAVE_LIBKENNY */

/* Define to 1 if libpng is detected */
#define HAVE_LIBPNG 1

/* Define to 1 if you have the <memory.h> header file. */
#define HAVE_MEMORY_H 1

/* Define to 1 if you have the `mmap' function. */
#define HAVE_MMAP 1

/* Define to 1 if you have the `mremap' function. */
/* #undef HAVE_MREMAP */

/* Define to 1 if you have the `sigaction' function. */
#define HAVE_SIGACTION 1

/* Define to 1 if you have the <signal.h> header file. */
#define HAVE_SIGNAL_H 1

/* Define to 1 if you have the <stdint.h> header file. */
#define HAVE_STDINT_H 1

/* Define to 1 if you have the <stdlib.h> header file. */
#define HAVE_STDLIB_H 1

/* Define to 1 if you have the <strings.h> header file. */
#define HAVE_STRINGS_H 1

/* Define to 1 if you have the <string.h> header file. */
#define HAVE_STRING_H 1

/* Define to 1 if _SC_PAGESIZE is available with sysconf() */
#define HAVE_SYSCONF_PAGESIZE 1

/* Define to 1 if _SC_PAGE_SIZE is available with sysconf() */
/* #undef HAVE_SYSCONF_PAGE_SIZE */

/* Define to 1 if you have the <sys/mman.h> header file. */
#define HAVE_SYS_MMAN_H 1

/* Define to 1 if you have the <sys/select.h> header file. */
#define HAVE_SYS_SELECT_H 1

/* Define to 1 if you have the <sys/stat.h> header file. */
#define HAVE_SYS_STAT_H 1

/* Define to 1 if you have the <sys/types.h> header file. */
#define HAVE_SYS_TYPES_H 1

/* Define to 1 if termios headers and functions are available */
#define HAVE_TERMIOS_H 1

/* Define to 1 if you have the <unistd.h> header file. */
#define HAVE_UNISTD_H 1

/* Define to 1 if XCB is detected */
#define HAVE_XCB 1

/* Define to the sub-directory where libtool stores uninstalled libraries. */
#define LT_OBJDIR ".libs/"

/* Define to 1 if assertions should be disabled. */
/* #undef NDEBUG */

/* Name of package */
#define PACKAGE "xpost"

/* Define to the address where bug reports for this package should be sent. */
#define PACKAGE_BUGREPORT "luser.droog.remove@gmail.com"

/* Define to the full name of this package. */
#define PACKAGE_NAME "xpost"

/* Define to the full name and version of this package. */
#define PACKAGE_STRING "xpost 0.0.1"

/* Define to the one symbol short name of this package. */
#define PACKAGE_TARNAME "xpost"

/* Define to the home page for this package. */
#define PACKAGE_URL ""

/* Define to the version of this package. */
#define PACKAGE_VERSION "0.0.1"

/* If using the C implementation of alloca, define if you know the
   direction of stack growth for your system; otherwise it will be
   automatically deduced at runtime.
        STACK_DIRECTION > 0 => grows toward higher addresses
        STACK_DIRECTION < 0 => grows toward lower addresses
        STACK_DIRECTION = 0 => direction of growth unknown */
/* #undef STACK_DIRECTION */

/* Define to 1 if you have the ANSI C header files. */
#define STDC_HEADERS 1

/* Define to 1 if you can safely include both <sys/time.h> and <time.h>. */
#define TIME_WITH_SYS_TIME 1

/* Enable extensions on AIX 3, Interix.  */
#ifndef _ALL_SOURCE
# define _ALL_SOURCE 1
#endif
/* Enable GNU extensions on systems that have them.  */
#ifndef _GNU_SOURCE
# define _GNU_SOURCE 1
#endif
/* Enable threading extensions on Solaris.  */
#ifndef _POSIX_PTHREAD_SEMANTICS
# define _POSIX_PTHREAD_SEMANTICS 1
#endif
/* Enable extensions on HP NonStop.  */
#ifndef _TANDEM_SOURCE
# define _TANDEM_SOURCE 1
#endif
/* Enable general extensions on Solaris.  */
#ifndef __EXTENSIONS__
# define __EXTENSIONS__ 1
#endif


/* Version number of package */
#define VERSION "0.0.1"

/* Define to 1 if large object are wanted */
/* #undef WANT_LARGE_OBJECT */

/* Define to the major version of the library */
#define XPOST_VERSION_MAJ 0

/* Define to the micro version of the library */
#define XPOST_VERSION_MIC 1

/* Define to the minor version of the library */
#define XPOST_VERSION_MIN 0

/* Define to 1 if debug mode is wanted */
#define _DEBUG 1

/* Define to 1 if on MINIX. */
/* #undef _MINIX */

/* Define to 2 if the system does not provide POSIX.1 features except with
   this defined. */
/* #undef _POSIX_1_SOURCE */

/* Define to 1 if you need to in order for `stat' and other things to work. */
/* #undef _POSIX_SOURCE */

/* Define to `unsigned int' if <sys/types.h> does not define. */
/* #undef size_t */

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

#129775

On 26/04/2018 05:56, luser droog wrote:
> On Wednesday, April 25, 2018 at 12:36:39 PM UTC-5, Bart wrote:

> There is a previous version of the project which has a much simpler
> build that does not require autotools. It has a more limited feature
> set overall and implements less of the PostScript standard, but it
> has a few features that the latest version does not. Notably, since
> the older Xpost uses Cairo for graphics it also has a pdf output device.
> 
> http://web.archive.org/web/20160404161603/https://code.google.com/p/xpost/downloads/detail?name=xpost2g.zip&can=2&q=

When you said it's much simpler, you weren't joking! (30 files, 0.3MB, 1 
directory versus 400 files, 13MB, 40 directories.) I'll check it out later.

> $ cat xpost/config.h
> /* config.h.  Generated from config.h.in by configure.  */
> /* config.h.in.  Generated from configure.ac by autoheader.  */
> 
> /* Define to one of `_getb67', `GETB67', `getb67' for Cray-2 and Cray-YMP
>     systems. This function is required for `alloca.c' support on those systems.
>     */
> /* #undef CRAY_STACKSEG_END */

(Might have to get that Cray out of the museum first.)

> /* Define to 1 if using `alloca.c'. */
> /* #undef C_ALLOCA */
> 
> /* Define to 1 if you have `alloca', as a function or macro. */
> #define HAVE_ALLOCA 1

If anyone else is having a go, this needs commenting out if you don't 
have alloca; /not/ defining it as 0...

(To get config.h included at all, in the sources it is guarded by 
HAVE_CONFIG_H (presumably defined elsewhere), and uses <config.h>. I had 
to remove the guards and change it to "config.h".

With the right settings I can proceed a bit further than before.)

-- 
bartc

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

#129777

On 26/04/2018 11:06, bartc wrote:
> On 26/04/2018 05:56, luser droog wrote:
>> On Wednesday, April 25, 2018 at 12:36:39 PM UTC-5, Bart wrote:
> 
>> There is a previous version of the project which has a much simpler
>> build that does not require autotools. It has a more limited feature
>> set overall and implements less of the PostScript standard, but it
>> has a few features that the latest version does not. Notably, since
>> the older Xpost uses Cairo for graphics it also has a pdf output device.
>>
>> http://web.archive.org/web/20160404161603/https://code.google.com/p/xpost/downloads/detail?name=xpost2g.zip&can=2&q= 
>>
> 
> When you said it's much simpler, you weren't joking! (30 files, 0.3MB, 1 
> directory versus 400 files, 13MB, 40 directories.) I'll check it out later.

Unfortunately that's a no-go because most files need mman.h, which 
doesn't appear to be used under Windows.

And later on it will need X11/Xlib.h, a big one.

-- 
bartc

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

#129802

bartc <bc@freeuk.com> wrote:
> On 25/04/2018 16:41, Ben Bacarisse wrote:
> > bartc <bc@freeuk.com> writes:
> 
> I'm just looking at what happens when you take an arbitrary C file, 
> which are supposed to be self-contained and compilable in any order (one 
> of the few advantages of C I will admit to), and run it through the 
> nearest C compiler to hand. It should not matter which one.
> 
> Even if I went through the normal channels, what does it know about my 
> compiler? Nothing.

You pretend to know nothing about configure.  To deny you this
excuse I will give you some explanation.  'configure' runs a
compiler trough a testsuite.  A sigle 'configure' run compiles
hundreds of test.  From results of tests 'configure' probably
knows more about compilers in question than you know about
some compilers.  Various HAVExxx symbols which appear in
preprocessor conditionals are defined by 'configure'.  By
refusing to run 'configure' you effectively give them all
false value.  But if you run 'configure' it is logically
impossible to get all of them false.  So you are effectively
giving contradictory set of defines and wonder why
compilation fails.

-- 
                              Waldek Hebisch

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

#129725

[...]
> All this I find quite typical of open source C code. It is 
> soul-destroying if you're trying to get an implementation to work, and 
> that fact that other compilers including MVSC can also have problems, is 
> not much comfort.

If you want to compile windows programs for instance, I think you 
need to be bug-to-bug compatible with Microsoft compiler and parser
the windows headers in the same way. (One sample I have is a macro 
that expand  \ \ to comment \\ and remove the line present in 
windows headers )

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

#129783

On Wed, 2018-04-25, bartc wrote:
> These are some observations about the difficulties of getting C source 
> code to compile, if you try and do it outside the confines of a 
> preferred compiler and build system.

It's not /preferred/ -- it's what the project defines and depends on.
Trying anything else is called /porting/.

> I took one github C project

Why not say which one?

> and tried to compile all the 48 C files in one subdirectory, but
> without using makefiles or taking any config steps. These are the
> results trying various Windows C compilers:

I understand you reject a lot of the conventional wisdom around
building C software, but if you pick a project and extract just
the .c and .h files, you can be pretty sure you'll not get an
executable out of it.

(Not that I'm particularly fond of configure scripts, or dependencies
on unique compiler details, or on libraries I never heard of.)

> (And for that reason, I'm retiring my C compiler for use with existing C 
> projects as it would be a never-ending task. It will be for new code.)

Didn't you do that a few weeks ago?

/Jorgen

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

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

#129785

In article <slrnpe3i3o.31ka.grahn+nntp@frailea.sa.invalid>,
Jorgen Grahn  <grahn+nntp@snipabacken.se> wrote:
>On Wed, 2018-04-25, bartc wrote:
>> These are some observations about the difficulties of getting C source 
>> code to compile, if you try and do it outside the confines of a 
>> preferred compiler and build system.
>
>It's not /preferred/ -- it's what the project defines and depends on.
>Trying anything else is called /porting/.
>
>> I took one github C project
>
>Why not say which one?

Why should he?

(And, in fact, in one of the posts here, he makes clear why he didn't state
it - to avoid embarrassing a fellow CLC poster.)

-- 
If you don't have faith, it's because you are reading the Bible with an
honest, truthful, real-answer seeking heart.

    - Rick C Hodgin -

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

#129798

On 25-04-18 17:21, bartc wrote:
> These are some observations about the difficulties of getting C source
> code to compile, if you try and do it outside the confines of a
> preferred compiler and build system.
> 
> I took one github C project and tried to compile all the 48 C files in
> one subdirectory, but without using makefiles or taking any config
> steps. These are the results trying various Windows C compilers:
> 
> gcc            47 files compiled successfully out of 48
> Tiny C         40 files
> Pelles C       32 files
> lccwin         17 files
> DMC            24 files
> MSVC           38 files
> bcc (mine)     36 files (after disabling a code-gen bug)
> 
> The one problem file for gcc was a missing header that I couldn't find
> anywhere.
> 
> Now, maybe this needs to have some configuration to build some config.h

Yes.

In such projects, usually you run "./configure", which detects whether
you have installed every required package, and detects which optional
packages you've installed.

The result is then written to a config.h file in the form of #define lines.

[...]
> #ifdef STDC_HEADERS
> # include <stdlib.h>
> # include <stddef.h>
> #else
> # ifdef HAVE_STDLIB_H

This would be defined in config.h or with a -D parameter in the Makefile.

> #  include <stdlib.h>
> # endif
> #endif
> 
> #ifdef HAVE_ALLOCA_H

Same.

> # include <alloca.h>
> #elif !defined alloca
> # ifdef __GNUC__
> #  define alloca __builtin_alloca
> # elif defined _AIX
> #  define alloca __alloca
> # elif defined _MSC_VER
> #  include <malloc.h>
> #  define alloca _alloca
> # elif !defined HAVE_ALLOCA
> #  ifdef  __cplusplus
> extern "C"
> #  endif
> void *alloca (size_t);
> # endif
> #endif
> 
> ---------------
> The problem was that alloca() declaration, that uses size_t, because the
> needed headers are included after this code. This doesn't affect gcc or
> MSVC because they have their own #elif blocks so this isn't seen.
> 
> All this I find quite typical of open source C code.

IME, provided your compiler is recognized by autoconf (which generates
the configure script), this all works like a breeze.

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

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

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

csiph-web