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

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

configure() -- a new C compiler preprocessor and code injection proposal

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

Contents

  configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-21 08:27 -0700
    Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-21 20:15 -0700
      Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-21 20:25 -0700
    Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-21 20:34 -0700
      Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-22 09:46 -0700
        Re: configure() -- a new C compiler preprocessor and code injection proposal Philip Lantz <prl@canterey.us> - 2015-08-22 13:15 -0700
        Re: configure() -- a new C compiler preprocessor and code injection proposal fir <profesor.fir@gmail.com> - 2015-08-22 13:25 -0700
    Re: configure() -- a new C compiler preprocessor and code injection proposal Ian Collins <ian-news@hotmail.com> - 2015-08-23 09:06 +1200
      Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-22 14:47 -0700
        Re: configure() -- a new C compiler preprocessor and code injection proposal Bartc <bc@freeuk.com> - 2015-08-22 23:09 +0100
          Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-22 15:21 -0700
            Re: configure() -- a new C compiler preprocessor and code injection proposal gordonb.qvmey@burditt.org (Gordon Burditt) - 2015-08-23 17:21 -0500
              Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-23 16:53 -0700
                Re: configure() -- a new C compiler preprocessor and code injection proposal gordonb.bkbkd@burditt.org (Gordon Burditt) - 2015-08-23 19:44 -0500
                  Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-23 19:08 -0700
                    Re: configure() -- a new C compiler preprocessor and code injection proposal gordonb.rnzzf@burditt.org (Gordon Burditt) - 2015-08-23 22:29 -0500
                      Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-23 20:43 -0700
                        Re: configure() -- a new C compiler preprocessor and code injection proposal gordonb.594yb@burditt.org (Gordon Burditt) - 2015-08-24 07:09 -0500
                          Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-24 05:30 -0700
                            Re: configure() -- a new C compiler preprocessor and code injection proposal Gordon Burditt <gordon@hammy.burditt.org> - 2015-08-24 07:39 -0500
                              Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-24 05:43 -0700
                                Re: configure() -- a new C compiler preprocessor and code injection proposal David Kleinecke <dkleinecke@gmail.com> - 2015-08-24 18:11 -0700
                                  Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-25 03:18 -0700
                                    Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-08-25 14:31 +0200
                                      Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-25 05:36 -0700
                                Re: configure() -- a new C compiler preprocessor and code injection proposal Richard Damon <Richard@Damon-Family.org> - 2015-08-24 22:01 -0400
                                  Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-25 03:22 -0700
                                    Re: configure() -- a new C compiler preprocessor and code injection proposal Bartc <bc@freeuk.com> - 2015-08-25 12:12 +0100
                                      Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-25 04:26 -0700
                                        Re: configure() -- a new C compiler preprocessor and code injection proposal Bartc <bc@freeuk.com> - 2015-08-25 13:09 +0100
                                          Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-25 05:20 -0700
                                            Re: configure() -- a new C compiler preprocessor and code injection proposal Bartc <bc@freeuk.com> - 2015-08-25 13:50 +0100
                                              Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-25 06:08 -0700
                                                Re: configure() -- a new C compiler preprocessor and code injection proposal gazelle@shell.xmission.com (Kenny McCormack) - 2015-08-25 14:34 +0000
                                                  Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-25 07:53 -0700
                                  Re: configure() -- a new C compiler preprocessor and code injection proposal jt@toerring.de (Jens Thoms Toerring) - 2015-08-25 12:53 +0000
                                    Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-25 06:19 -0700
                                      Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-08-25 15:47 +0200
                                        Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-25 07:23 -0700
                                          Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-08-25 16:41 +0200
                                            Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-25 08:08 -0700
                              Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-24 05:54 -0700
                    Re: configure() -- a new C compiler preprocessor and code injection proposal Bartc <bc@freeuk.com> - 2015-08-24 09:17 +0100
          Re: configure() -- a new C compiler preprocessor and code injection proposal gazelle@shell.xmission.com (Kenny McCormack) - 2015-08-22 22:22 +0000
            Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-22 15:31 -0700
          Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-08-23 23:13 +0200
        Re: configure() -- a new C compiler preprocessor and code injection proposal fir <profesor.fir@gmail.com> - 2015-08-22 15:40 -0700
          Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-22 16:00 -0700
            Re: configure() -- a new C compiler preprocessor and code injection proposal fir <profesor.fir@gmail.com> - 2015-08-22 16:05 -0700
        Re: configure() -- a new C compiler preprocessor and code injection proposal Ian Collins <ian-news@hotmail.com> - 2015-08-23 11:07 +1200
          Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-22 16:15 -0700
    Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-22 15:01 -0700
      Re: configure() -- a new C compiler preprocessor and code injection proposal Bartc <bc@freeuk.com> - 2015-08-22 23:16 +0100
        Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-22 15:24 -0700
    Re: configure() -- a new C compiler preprocessor and code injection proposal gordonb.i2ffz@burditt.org (Gordon Burditt) - 2015-08-22 17:40 -0500
      Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-22 15:55 -0700
        Re: configure() -- a new C compiler preprocessor and code injection proposal Ian Collins <ian-news@hotmail.com> - 2015-08-23 11:13 +1200
          Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-22 16:19 -0700
            Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-22 16:29 -0700
              Re: configure() -- a new C compiler preprocessor and code injection proposal Richard Damon <Richard@Damon-Family.org> - 2015-08-22 21:04 -0400
        Re: configure() -- a new C compiler preprocessor and code injection proposal gordonb.501pe@burditt.org (Gordon Burditt) - 2015-08-23 18:25 -0500
          Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-23 17:18 -0700
            Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-08-24 10:41 +0200
      Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-08-23 22:55 +0200
        Re: configure() -- a new C compiler preprocessor and code injection proposal gordonb.ca5vg@burditt.org (Gordon Burditt) - 2015-08-23 18:43 -0500
          Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-08-24 10:57 +0200
            Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-24 05:40 -0700
              Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-08-24 15:07 +0200
                Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-24 06:29 -0700
                  Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-08-24 15:56 +0200
                    Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-24 07:18 -0700
                      Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-08-24 17:22 +0200
              Re: configure() -- a new C compiler preprocessor and code injection proposal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-24 14:36 +0100
                Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-24 06:49 -0700
    Re: configure() -- a new C compiler preprocessor and code injection proposal "Morten W. Petersen" <morphex@gmail.com> - 2015-08-23 12:55 +0200
      Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-23 04:58 -0700
      Re: configure() -- a new C compiler preprocessor and code injection proposal Bartc <bc@freeuk.com> - 2015-08-23 13:03 +0100
        Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-23 05:20 -0700
          Re: configure() -- a new C compiler preprocessor and code injection proposal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-23 16:59 +0100
            Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-23 09:34 -0700
              Re: configure() -- a new C compiler preprocessor and code injection proposal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-23 20:10 +0100
            Re: configure() -- a new C compiler preprocessor and code injection proposal gazelle@shell.xmission.com (Kenny McCormack) - 2015-08-23 16:36 +0000
        Re: configure() -- a new C compiler preprocessor and code injection proposal "Morten W. Petersen" <morphex@gmail.com> - 2015-08-23 14:27 +0200
          Re: configure() -- a new C compiler preprocessor and code injection proposal Bartc <bc@freeuk.com> - 2015-08-23 13:35 +0100
            Re: configure() -- a new C compiler preprocessor and code injection proposal "Morten W. Petersen" <morphex@gmail.com> - 2015-08-23 15:08 +0200
              Re: configure() -- a new C compiler preprocessor and code injection proposal Keith Thompson <kst-u@mib.org> - 2015-08-23 14:27 -0700
                Re: configure() -- a new C compiler preprocessor and code injection proposal "Morten W. Petersen" <morphex@gmail.com> - 2015-08-31 19:24 +0200
                  Re: configure() -- a new C compiler preprocessor and code injection proposal James Kuyper <jameskuyper@verizon.net> - 2015-08-31 13:53 -0400
                    Re: configure() -- a new C compiler preprocessor and code injection proposal "Morten W. Petersen" <morphex@gmail.com> - 2015-08-31 19:59 +0200
                      Re: configure() -- a new C compiler preprocessor and code injection proposal Bartc <bc@freeuk.com> - 2015-08-31 19:10 +0100
                      Re: configure() -- a new C compiler preprocessor and code injection proposal Keith Thompson <kst-u@mib.org> - 2015-08-31 11:27 -0700
                      Re: configure() -- a new C compiler preprocessor and code injection proposal James Kuyper <jameskuyper@verizon.net> - 2015-08-31 15:40 -0400
                  Re: configure() -- a new C compiler preprocessor and code injection proposal Keith Thompson <kst-u@mib.org> - 2015-08-31 11:22 -0700
                    Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-31 12:18 -0700
                      Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-09-01 10:09 +0200
                        Re: configure() -- a new C compiler preprocessor and code injection proposal Keith Thompson <kst-u@mib.org> - 2015-09-01 08:12 -0700
                          Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-09-01 22:19 +0200
                    Re: configure() -- a new C compiler preprocessor and code injection proposal Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 14:47 -0700
              Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-08-23 23:13 +0200
                Re: configure() -- a new C compiler preprocessor and code injection proposal "Morten W. Petersen" <morphex@gmail.com> - 2015-08-31 22:27 +0200
                  Re: configure() -- a new C compiler preprocessor and code injection proposal supercat@casperkitty.com - 2015-08-31 15:00 -0700
                    Re: configure() -- a new C compiler preprocessor and code injection proposal "Morten W. Petersen" <morphex@gmail.com> - 2015-09-01 00:56 +0200
                      Re: configure() -- a new C compiler preprocessor and code injection proposal James Kuyper <jameskuyper@verizon.net> - 2015-08-31 20:11 -0400
                        Re: configure() -- a new C compiler preprocessor and code injection proposal "Morten W. Petersen" <morphex@gmail.com> - 2015-09-01 12:26 +0200
                          Re: configure() -- a new C compiler preprocessor and code injection proposal James Kuyper <jameskuyper@verizon.net> - 2015-09-01 13:37 -0400
                            Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-09-01 22:18 +0200
                              Re: configure() -- a new C compiler preprocessor and code injection proposal James Kuyper <jameskuyper@verizon.net> - 2015-09-01 16:31 -0400
                            Re: configure() -- a new C compiler preprocessor and code injection proposal "Morten W. Petersen" <morphex@gmail.com> - 2015-09-04 07:15 +0200
                              Re: configure() -- a new C compiler preprocessor and code injection proposal James Kuyper <jameskuyper@verizon.net> - 2015-09-04 07:28 -0400
                  Re: configure() -- a new C compiler preprocessor and code injection proposal James Kuyper <jameskuyper@verizon.net> - 2015-08-31 20:02 -0400
                  Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-09-01 09:41 +0200
                    Re: configure() -- a new C compiler preprocessor and code injection proposal "Morten W. Petersen" <morphex@gmail.com> - 2015-09-01 12:24 +0200
                      Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-09-01 14:14 +0200
                        Re: configure() -- a new C compiler preprocessor and code injection proposal "Morten W. Petersen" <morphex@gmail.com> - 2015-09-04 07:22 +0200
                          Re: configure() -- a new C compiler preprocessor and code injection proposal James Kuyper <jameskuyper@verizon.net> - 2015-09-04 07:38 -0400
                      Re: configure() -- a new C compiler preprocessor and code injection proposal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-01 13:14 +0100
                      Re: configure() -- a new C compiler preprocessor and code injection proposal James Kuyper <jameskuyper@verizon.net> - 2015-09-01 11:07 -0400
              Re: configure() -- a new C compiler preprocessor and code injection proposal gordonb.vg6n6@burditt.org (Gordon Burditt) - 2015-08-23 19:29 -0500
                Re: configure() -- a new C compiler preprocessor and code injection proposal Bartc <bc@freeuk.com> - 2015-08-24 09:32 +0100
                  Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-08-24 11:43 +0200
                    Re: configure() -- a new C compiler preprocessor and code injection proposal Bartc <bc@freeuk.com> - 2015-08-24 11:01 +0100
                      Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-08-24 12:24 +0200
                        Re: configure() -- a new C compiler preprocessor and code injection proposal Bartc <bc@freeuk.com> - 2015-08-24 12:06 +0100
                          Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-08-24 14:21 +0200
        Re: configure() -- a new C compiler preprocessor and code injection   proposal Ian Collins <ian-news@hotmail.com> - 2015-08-24 07:48 +1200
          Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-23 12:56 -0700
      Re: configure() -- a new C compiler preprocessor and code injection proposal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-23 13:45 +0100
        Re: configure() -- a new C compiler preprocessor and code injection proposal Bartc <bc@freeuk.com> - 2015-08-23 14:38 +0100
          Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-23 06:43 -0700
            Re: configure() -- a new C compiler preprocessor and code injection proposal Bartc <bc@freeuk.com> - 2015-08-23 15:00 +0100
              Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-23 07:54 -0700
                Re: configure() -- a new C compiler preprocessor and code injection proposal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-23 19:28 +0100
                  Re: configure() -- a new C compiler preprocessor and code injection proposal mark.bluemel@gmail.com - 2015-08-24 00:31 -0700
          Re: configure() -- a new C compiler preprocessor and code injection proposal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-23 16:17 +0100
            Re: configure() -- a new C compiler preprocessor and code injection proposal Bartc <bc@freeuk.com> - 2015-08-23 16:30 +0100
              Re: configure() -- a new C compiler preprocessor and code injection proposal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-23 19:44 +0100
        Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-23 06:40 -0700
          Re: configure() -- a new C compiler preprocessor and code injection proposal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-23 16:29 +0100
      Re: configure() -- a new C compiler preprocessor and code injection proposal gordonb.kj6kb@burditt.org (Gordon Burditt) - 2015-08-23 19:13 -0500
    Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-04 05:10 -0700

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

#68316

On Tuesday, August 25, 2015 at 10:41:34 AM UTC-4, David Brown wrote:
> On 25/08/15 16:23, Rick C. Hodgin wrote:
> > However, I will produce an example at some point.  And, just so you
> > know, you can see one at the top of this thread.  It's the second
> > post I made down if you view it in a chronological view.
> 
> No, that's not an example that provides any clarification.  Give a short
> but /complete/ example program using configure blocks.  No more, no
> less.  Don't try to include everything.

How is it not an example?  It demonstrates the ability to direct the
compilation through the configure block.

> > In that example, the configure block, which at that point I called
> > a "configure(struct SConfig* c)" function, is used to direct the
> > compilation.  In that particular case, it uses the source file that
> > it's contained in, and alters the outputs to compile for three
> > different architectures.
> > 
> > I used that simplistic example to see how other features could be
> > made.  It could also compile for ARM on Linux, and ARM on something
> > else, and i686 on Mac, and i686 on Windows, and i686 on Linux, and
> > so on.
> 
> It is not an example - it is meaningless.

It is an example.  It is code that would be used to direct the compile
through the configure block.  And how is it meaningless?

> Here's a hint - if you write "These would be things like..." or "et
> cetera", you're doing it wrong.

I literally had my jaw drop open when I read this reply from you.
I don't see it, David.  I'm stunned.

I don't know how to do it differently.  There seems to be some form
of rigid mechanical form you and Ben require, such as with my RDC
specs file I posted once and Ben said it's not a spec.  It is a
spec, it's just not a spec like the C standard because I haven't
had (1) that kind of time to create something like that, and (2)
the interest to do so.  And there's something similar here with
regards to this idea.

I did post an example above which demonstrates how to direct the
compile.  Apart from syntax errors, it would be a valid case.

And beyond that...

It's to provide the general idea, so that anyone exerting thought on
the idea (and probably for those few to whom the idea would also
resonate) would see the broad strokes I offer, and then rather than
me filling in the details for them presenting a photograph, they can
fill in the details with their own thought, using their unique and
special talents to augment the idea as they saw it, reporting back,
which then sparks even more thought amongst the group, resulting in
a far better idea being crafted than had I handed you a completed
video.

By me giving you a storyboard, it's easier to edit, expand, for
people to put the uniqueness of themselves in there, and for the
idea to grow beyond being handed an instruction manual on how to
use that which is made out of iron and stone.

Best regards,
Rick C. Hodgin

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

#68230

On Monday, August 24, 2015 at 8:40:05 AM UTC-4, Gordon Burditt wrote:
> >> Note:  if it's not obvious, the fact that I'm asking questions means
> >> I don't understand something.
> > 
> > Gordon, I wrote a lengthy response to your post, which I've saved to
> > a temporary file and can reclaim if need be, but to answer the bulk
> > of your questions simply:
> > 
> > -----
> > Configure is only needed when configure is needed.  It
> 
> You said you wanted it to replace makefiles.  If that's true, it's
> *ALWAYS* needed, and I think it means configure needs way more power
> than you've imagined.  If I'm wrong, I apologize, but I'm pretty sure
> I read that in one of your posts.
> 
> If configure works on individual compilations, where is the information
> on how to *LINK* executables together?  I find "gcc *.c" to hardly
> ever be appropriate.  All of the *.c files may not needed in the
> link (and extra .c files may kill the link), and additional libraries
> are often needed.

I'll write up the full proposal at some point.  Remember, I'm like
Donald Trump:  "Just trust me.  It'll be great!"  :-)

I look at it this way:  I would like to have this ability, and
since I'm the one defining it, I will be the one who makes sure
that all of the abilities that are needed are in there.  And
there is always room for expansion.

Best regards,
Rick C. Hodgin

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

#68208

On 24/08/2015 03:08, Rick C. Hodgin wrote:
> On Sunday, August 23, 2015 at 8:44:53 PM UTC-4, Gordon Burditt wrote:

>> If you put multiple files on the gcc command line, it compiles
>> each file separately from any other file.  Adding configure.c
>> to the command line isn't going to make changes the other files
>> listed.
>
> It may be enough then to use gcc --enable-configure which then
> specifically looks for a configure.h file, or a named option as
> in "--enable-configure other_configure.h" or some other syntax.

My experience is that if an idea is that difficult to put across, then 
forget it. I've read most of your posts and still have no idea what 
you're on about. Partly because you've refused a side-by-side example 
that will let people evaluate it.

Look how much trouble I had in propounding the idea of binary literals. 
Everyone understands what they are and can do, I supplied plenty of 
examples, and yet most people on this group were against it.

(And yes I've also toyed with the idea of meta-programming via an 
embedded language. But there were enough problems that I gave up on it.)

-- 
Bartc

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

#68052

In article <mrarr1$3ii$1@dont-email.me>, Bartc  <bc@freeuk.com> wrote:
...
>This is all rather meaningless. Or rather, it could mean almost anything.

Bravo!  That's it!

Rick is turning out to be the Donald Trump of CLC.

Trust me, you'l love it.  It'll be terrific.  Just trust me.

-- 
If it seems like I'm not responding to some moronic criticism that you've posted in
response to one of my posts, be aware that I do not argue with idiots.

It doesn't mean you've won anything...

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

#68054

On Saturday, August 22, 2015 at 6:22:38 PM UTC-4, Kenny McCormack wrote:
> In article <mrarr1$3ii$1@dont-email.me>, Bartc  <bc@freeuk.com> wrote:
> ...
> >This is all rather meaningless. Or rather, it could mean almost anything.
> 
> Bravo!  That's it!
> 
> Rick is turning out to be the Donald Trump of CLC.
>
> Trust me, you'l love it.  It'll be terrific.  Just trust me.

I am asking for input from people on this concept.  I believe
that's a standard operating procedure for a new idea.  As it
stands today, I happen to think it's an absolutely amazing
feature.  But, it doesn't exist yet and I can see how people
would have a difficult time understanding a new thing without
a concrete example.  I'm just thinking things through right
now before I commit to coding it.

> -- 
> If it seems like I'm not responding to some moronic criticism that you've posted in
> response to one of my posts, be aware that I do not argue with idiots.
> It doesn't mean you've won anything...

Kenny, you're going to find some day that you were wrong about the way
you handled and approached life, and the people God gave you to share
with you in your life.  I pray this day comes while you are still on
this side of the grave, because if you only find it out on that side
of the grave there will be no recovery.

Love is the better way.  Helping people is the better way.  Being kind
to one another, compensating for their weaknesses by your strengths is
the better way.

Calling people names, being mean, it only hurts them, and you, and it
is a way to be that nobody should want a part of.  Be loving instead.
Be helping instead.  Be the one who encourages someone else to be
better today than they were yesterday.  Give them the tools they need
that you possess to augment their best offering with the refinement
you're capable of giving, so that all are uplifted, edified, growing,
and prospering together.

It is the far far far better way.  I pray you learn that some day soon.

Best regards,
Rick C. Hodgin

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

#68154

On 23/08/15 00:09, Bartc wrote:
>
> We need a concrete example showing what it looks like with and without
> the new feature.
>
> The most important thing is what the overall code looks like. If a
> conditional #if selects between blocks of code A and B, then it seems to
> me that you need to provide both A and B no matter what method is used.
>
> If your method means someone is presented with just A, or B, then that's
> nice, but you're only seeing half the code (the same problem as when you
> examine the preprocessor output).
>
> And if block A or B is constructed by a bit of code, then you're not
> seeing any of it!

I think this is the key point.  Long before we have a list of 
complicated syntaxes, we need a simple, clear, and complete example from 
Rick - and then we can look at how it compares to more conventional 
solutions (macros, #if/#endif, ./configure scripts, additional 
preprocessing, and even - though it be heresy in c.l.c. - using C++).

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

#68055

W dniu sobota, 22 sierpnia 2015 23:48:06 UTC+2 użytkownik Rick C. Hodgin napisał:
> On Saturday, August 22, 2015 at 5:07:06 PM UTC-4, Ian Collins wrote:
> > Rick C. Hodgin wrote:
> > > Morten W. Petersen came up with an idea for a configure() function
> > > that would be compiled before the rest of the source code is compiled.
> > > It would allow for C program logic to be used to allow the rest of
> > > the source code to have fixups applied against it for compilation.
> > >
> > > I think it's one of the most original and best ideas I've heard of
> > > for C/C++ and similar languages which use some form of preprocessing
> > > today.
> > 
> > What problem are you attempting to solve that can't be solved with 
> > standard language features?  C++ already has support for running code 
> > before (and after) main.
> 
> It is a pre-compile configuration feature that is encapsulated in the
> source code being compiled, requiring only the compiler to handle the
> configuration (no external scripts, nothing apart from the source code
> base).  It can fixup and inject code based on compile-time settings,
> repeating even operations in a loop for multiple targets from a single
> compile line, allowing the possibility of recovering from some common
> compile errors by automatically fixing up the missing lib reference,
> or inserting an (unsigned int) on signed/unsigned compares, etc.
> 
> It basically gives programmable control over how the the compiler
> compiles, and has the ability to fixup code for various reasons
> which could (1) replace many macros and #define/#end blocks, (2)
> recover from errors, and (3) perform custom code which analyzes
> the compile results, creating reports, storing historical trends,
> auto-updating information in a source code repository, etc., all
> from inside it's own code base using only the compiler.
> 
> Best regards,
> Rick C. Hodgin

(i got tens of much better ideas)
better idea would be for example more native 
(integrated) support for sse types and operations

for example this 

__attribute__((force_align_arg_pointer)) 
 __m128i  mandelbrot_n_sse(  __m128 cre,  __m128 cim,  int max_iter ) 

{ 
   __m128 re = _mm_setzero_ps(); 
   __m128 im = _mm_setzero_ps(); 


      __m128 _1 = _mm_set_ps1(1.); 
     __m128 _4 = _mm_set_ps1(4.); 

  __m128 iteration_counter = _mm_set_ps1(0.); 


    for(int n=0; n<=max_iter; n++) 
    { 

    __m128 re2 =  _mm_mul_ps(re, re); 
    __m128 im2 =  _mm_mul_ps(im, im); 
    __m128 radius2 = _mm_add_ps(re2,im2); 

    __m128 compare_mask = _mm_cmplt_ps( radius2, _4); 
    iteration_counter = _mm_add_ps( iteration_counter, _mm_and_ps(compare_mask, _1) ); 
    if (_mm_movemask_ps(compare_mask)==0) break; 

    __m128 ren = _mm_add_ps( _mm_sub_ps(re2, im2), cre); 
    __m128 reim = _mm_mul_ps(re, im); 

    __m128 imn = _mm_add_ps( _mm_add_ps(reim, reim), cim); 

     re = ren; 
     im = imn; 


    } 

    __m128i n = _mm_cvtps_epi32(iteration_counter); 

    return n; 
} 

could look like



int4  mandelbrot_n_sse(  float4 cre,  float4 cim,  int max_iter )
{

   float4 re, im, iter_count = 0;

    for(max_iter)
    {

     int4 less = re * re + im * im  <  4.0;

     if (!less)  break;

     iter_count +=  less & 1.0 ;

      re, im  = re * re - im * im + cre,
                  2  * re * im + cim ;

    }

    return (int4) iter_count;
}

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

#68058

On Saturday, August 22, 2015 at 6:40:14 PM UTC-4, fir wrote:
> (i got tens of much better ideas)

fir, given your lack of knowledge with regards to the C programming
language, and programming concepts in general, as exhibited by your
many posts, questions and types of questions, and by the several
examples you've offered, I do not believe you have a sufficient skill
set in this area to understand what exactly it is I'm proposing.  As
such, I will not be responding to your future posts on this topic.

I would advise you to read and try to understand.  If you have
something beneficial to offer on this subject, I would look forward
to reading it.

Best regards,
Rick C. Hodgin

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

#68059

W dniu niedziela, 23 sierpnia 2015 01:00:40 UTC+2 użytkownik Rick C. Hodgin napisał:
> On Saturday, August 22, 2015 at 6:40:14 PM UTC-4, fir wrote:
> > (i got tens of much better ideas)
> 
> fir, given your lack of knowledge with regards to the C programming
> language, and programming concepts in general, as exhibited by your
> many posts, questions and types of questions, and by the several
> examples you've offered, I do not believe you have a sufficient skill
> set in this area to understand what exactly it is I'm proposing.  As
> such, I will not be responding to your future posts on this topic.
> 
> I would advise you to read and try to understand.  If you have
> something beneficial to offer on this subject, I would look forward
> to reading it.
> 

not a problem
(wonder what exactly lack of knowledge you mean

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

#68060

Rick C. Hodgin wrote:
> On Saturday, August 22, 2015 at 5:07:06 PM UTC-4, Ian Collins wrote:
>> Rick C. Hodgin wrote:
>>> Morten W. Petersen came up with an idea for a configure() function
>>> that would be compiled before the rest of the source code is compiled.
>>> It would allow for C program logic to be used to allow the rest of
>>> the source code to have fixups applied against it for compilation.
>>>
>>> I think it's one of the most original and best ideas I've heard of
>>> for C/C++ and similar languages which use some form of preprocessing
>>> today.
>>
>> What problem are you attempting to solve that can't be solved with
>> standard language features?  C++ already has support for running code
>> before (and after) main.
>
> It is a pre-compile configuration feature that is encapsulated in the
> source code being compiled, requiring only the compiler to handle the
> configuration (no external scripts, nothing apart from the source code
> base).

That is injecting platform specifics into the code base when they really 
belong in the build environment.  I guess using your dynamic web analogy 
it's similar to embedding styles in HTML rather than than using CSS files.

The same results can be achieved through one or more platform specific 
headers.

> It can fixup and inject code based on compile-time settings,
> repeating even operations in a loop for multiple targets from a single
> compile line, allowing the possibility of recovering from some common
> compile errors by automatically fixing up the missing lib reference,
> or inserting an (unsigned int) on signed/unsigned compares, etc.

This is a bad idea, too many opportunities for inappropriate "fixes".

> It basically gives programmable control over how the the compiler
> compiles, and has the ability to fixup code for various reasons
> which could (1) replace many macros and #define/#end blocks, (2)
> recover from errors, and (3) perform custom code which analyzes
> the compile results, creating reports, storing historical trends,
> auto-updating information in a source code repository, etc., all
> from inside it's own code base using only the compiler.

1) replaces one form of code with another, possible more complex form.
2) is dangerous.
3) is already better handled by specialised tools.

-- 
Ian Collins

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

#68062

On Saturday, August 22, 2015 at 7:07:14 PM UTC-4, Ian Collins wrote:
> 1) replaces one form of code with another, possible more complex form.
> 2) is dangerous.
> 3) is already better handled by specialised tools.

I appreciate your input, Ian.  Thank you.

Best regards,
Rick C. Hodgin

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

#68048

The compiler would process and compile the configure block of code
(or blocks of code) first, and then run them before doing any other
compilation on the source code.

If there was a "compile;" command executed in configure, then once
it runs the blocks of code, it's done and exits.  If no "compile;"
command was found, it then proceeds to do a compile after things
are fixed up by whatever the configure code did.

The configure code could perform tests on the runtime environment
and fixup the needs of the source code for that machine, basically
doing what "./configure" does today, but without any other tools
being required, with all of it being done from inside the compiler
with a few new commands and extensions to provide support for this
ability.

Best regards,
Rick C. Hodgin

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

#68050

On 22/08/2015 23:01, Rick C. Hodgin wrote:
> The compiler would process and compile the configure block of code
> (or blocks of code) first, and then run them before doing any other
> compilation on the source code.
>
> If there was a "compile;" command executed in configure, then once
> it runs the blocks of code, it's done and exits.  If no "compile;"
> command was found, it then proceeds to do a compile after things
> are fixed up by whatever the configure code did.
>
> The configure code could perform tests on the runtime environment
> and fixup the needs of the source code for that machine, basically
> doing what "./configure" does today, but without any other tools
> being required, with all of it being done from inside the compiler
> with a few new commands and extensions to provide support for this
> ability.

./configure seems to be something that's run before compiling any 
modules of a project.

If you're going to put what it does within the 100 .c and .h files 
comprising an application, where would it go: which file?

Suppose the purpose of ./configure is to create a 10000-line main 
module, how will it work if the generating code is inside that main 
module? Will it have to do that every time it's compiled, or will it 
save the results? If the latter, how will it work? It sounds as though 
such things need to exist outside of the C source code.

-- 
Bartc

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

#68053

On Saturday, August 22, 2015 at 6:16:59 PM UTC-4, Bart wrote:
> On 22/08/2015 23:01, Rick C. Hodgin wrote:
> > The compiler would process and compile the configure block of code
> > (or blocks of code) first, and then run them before doing any other
> > compilation on the source code.
> >
> > If there was a "compile;" command executed in configure, then once
> > it runs the blocks of code, it's done and exits.  If no "compile;"
> > command was found, it then proceeds to do a compile after things
> > are fixed up by whatever the configure code did.
> >
> > The configure code could perform tests on the runtime environment
> > and fixup the needs of the source code for that machine, basically
> > doing what "./configure" does today, but without any other tools
> > being required, with all of it being done from inside the compiler
> > with a few new commands and extensions to provide support for this
> > ability.
> 
> ./configure seems to be something that's run before compiling any 
> modules of a project.
> 
> If you're going to put what it does within the 100 .c and .h files 
> comprising an application, where would it go: which file?

The .c and .h source files are loaded like normal.  All configure
blocks are designated with:

    configure
    {
        // configure code goes here
    }

Multiple configure { ... } blocks can exist, and they will be
queued and executed in a top-down manner as they are encountered
in source code.

> Suppose the purpose of ./configure is to create a 10000-line main 
> module, how will it work if the generating code is inside that main 
> module? Will it have to do that every time it's compiled, or will it 
> save the results? If the latter, how will it work? It sounds as though 
> such things need to exist outside of the C source code.

It depended on how the user set it up.  If you have a ./configure
script which generates 10,000 lines of code then your commensurate
configure script in the C source code would have to do the same,
generating a permanent output file which is then referenced as an
#include file in the source code.  It could look for stale results,
dependencies that have changed, different environments, etc., and
then re-build, or simply re-use what is already there.

It removes the need for ./configure, and moves it into C source code
and the one compiler which handles the configure ability.

Best regards,
Rick C. Hodgin

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

#68056

> Morten W. Petersen came up with an idea for a configure() function
> that would be compiled before the rest of the source code is compiled.
> It would allow for C program logic to be used to allow the rest of
> the source code to have fixups applied against it for compilation.
> 
> I think it's one of the most original and best ideas I've heard of
> for C/C++ and similar languages which use some form of preprocessing
> today.

It appears to make source code very difficult to read.
If I am looking at a section of code, I have to look over all of
the code to determine whether this is Windows-only code, or it's
supposed to be generic.  Granted, the same problem occurs with
#if PLATFORM == WINDOWS
...
#endif
but if you don't go too crazy and make the contents of #if ... #endif
thousands of lines long, you at least have a hint that it's
conditional.  At least with goto there's a label at the point
that might get branched to out of the normal code flow.
With the preprocessor, there's at least an identifier that
gets replaced with something that can be searched for.

> Some additional abilities which allow by-position inserting:
> 
>      inject [[before, after] myFunction()] = { ... };
>      replace myFunction() with { ... };
>      prepend code in myFunction() with { ... };
>      append code in myFunction() with { ... };

Is this supposed to inject code *INTO* functions, or inject code
*BEFORE* and *AFTER* functions?  

Especially if this is conditional on something, this makes it nearly
impossible to be sure you are looking at the actual code that is
in use.  There isn't even a #if 100 lines before the code that
gets replaced to warn me about it.

configure() sounds like a great way to inject malware into source
code without people noticing.  At least with #define, you can
only replace one identifier, and if you are wondering if it is
replaced, you have that identifier to search for elsewhere in the 
code.  

>      struct SConfig
>      {
>           int    switchc;     // Number of command-line switches
>           char** switchv;     // Access to each switch
> 
>           int    sourcecodec; // Number of source code files
>           char** sourcecodev; // Access to each source code name
> 
>           int    includec;    // Number of include files
>           char** includev;    // Access to each include file
> 
>           int    envc;        // Number of environment constants
>           char** envv;        // Access to environment constants
>           // Note:  These would be things like:
>           //            "os=linux"
>           //            "cpu=i686"
>           //            "machine=rickh"
>           //            "compiler=gcc-4.8.0"
> 
>           // Et cetera
>      };

You have now thrown the idea of cross-compilation into the dumpster.

Also, isn't this supposed to be a pre-processor for a (single)
compilation?  (That is, it doesn't do an entire executable or library
all at once.) A single compilation probably has *ONE* source (.c)
file, and a few .h files.

Also, since command-line switches are *NOT* standardized, how is
the program supposed to make productive use of this information?
The number of include files in any given compilation is *NOT* necessarily
the same for each source file.  It's great for an Obfuscated C
contest where only the *FIRST* file on the command line generates
any code.

I suppose this is an attempt to make sure that the object generated is
different for every machine that ever existed.  Of course __TIME__ and
__DATE__ do that, and to a lesser extent __FILE__ does that, but
the possibilities here are greatly multiplied.

>      void configure(struct SConfig* c)
>      {
>          // Reference to c-> item would be available
> 
>          // Commands would be available to search envv options:
>          if (isFound(c->env, "os", "linux") {
>              // Specific code for Linux goes here
>          } else if (isFound(c->env, "os", "windows") {
>              // Specific code for Windows goes here
>          }
> 
>          // Et cetera
>      }
> 

One idea I DON'T see in this proposal is #ifinclude, and I don't see
a way to simulate it.  

#ifinclude <getopt.h>
... code if you found <getopt.h> ...
#else
... code if <getopt.h> wasn't found or is otherwise unavailable ...
#endif

This could replace a lot of work done by GNU "configure" scripts
with HAVE_MALLOC_H, etc., variables used to indicate which include
files are available.

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

#68057

On Saturday, August 22, 2015 at 6:40:17 PM UTC-4, Gordon Burditt wrote:
> > Morten W. Petersen came up with an idea for a configure() function
> > that would be compiled before the rest of the source code is compiled.
> > It would allow for C program logic to be used to allow the rest of
> > the source code to have fixups applied against it for compilation.
> > 
> > I think it's one of the most original and best ideas I've heard of
> > for C/C++ and similar languages which use some form of preprocessing
> > today.
> 
> It appears to make source code very difficult to read.
> If I am looking at a section of code, I have to look over all of
> the code to determine whether this is Windows-only code, or it's
> supposed to be generic.  Granted, the same problem occurs with
> #if PLATFORM == WINDOWS
> ...
> #endif

In the source code you could replace those #if..#endif blocks with
the new token form, like $this$;.  As such, the token takes on the
name of its operation, and then because you see the $token$; form,
you know to look in the configure script.  In fact, because this
new ability is a new ability, it should have a closely coupled
relationship to an API available for a text editor, for example,
which allows for meta data on each source code line that the compiler
would know about, such as where that $token$; is actually defined,
in which configure script, which then shows you that content nearby.

The same is available with #if token1 == token2 on the token1 and
token2 names, but it's not quite the same.  In source code you could
have this:

    void my_function(void)
    {
    #if PLATFORM == WINDOWS
        // Code goes here
    #elif PLATFORM == LINUX
        // Code goes here
    #else
        // Fallback code goes here
    #endif

         // Other code
    }

...replaced with something which conveys what it's doing:

    void my_function(void)
    {
        $initialization_code_for_my_function$;

         // Other code
    }

And then in your configure script, you could have it setup in
the logic blocks there, putting all platform-specific code in
one area, and also allowing for tokens to be tracked through
the platform paths to find out that you do not have the token
defined under the "os=linux" path, for example, allowing the
editor or compiler to provide that information for you upon
inquiry (as by API call by the text editor, or a switch which
enables that kind of warning in the configure compiler).

> but if you don't go too crazy and make the contents of #if ... #endif
> thousands of lines long, you at least have a hint that it's
> conditional.  At least with goto there's a label at the point
> that might get branched to out of the normal code flow.
> With the preprocessor, there's at least an identifier that
> gets replaced with something that can be searched for.
> 
> > Some additional abilities which allow by-position inserting:
> > 
> >      inject [[before, after] myFunction()] = { ... };
> >      replace myFunction() with { ... };
> >      prepend code in myFunction() with { ... };
> >      append code in myFunction() with { ... };
> 
> Is this supposed to inject code *INTO* functions, or inject code
> *BEFORE* and *AFTER* functions?

All three.

    inject before myFunction() = { /* New code before myFunction()
                                      goes here */ };

    replace myFunction() = { /* The *NEW* myFunction() is used by
                                the code in this block */ };

These two will inject code after the variable declarations, and
before the first line of non-variable-declaration source code (for
prepend), and after the last line of code before the closing } (for
append).

    prepend code in myFunction() with { .... };
    append code in myFunction() with { .... };

If there are special case exits from the function, it would have
to be handled differently, such as by using a $token$; which is
then inserted by name using something like this:

    replace $token$ in myFunction() with { ... };

> Especially if this is conditional on something, this makes it nearly
> impossible to be sure you are looking at the actual code that is
> in use.  There isn't even a #if 100 lines before the code that
> gets replaced to warn me about it.

There are two ways this pre-processor would operate.  (1) it would
be like a macro preprocessor where it doesn't alter the source code,
or (2) it could write out the changed source code after processing.
I personally think the idea of having (2) is pretty amazing.  The
possibility then exists to have a track from original source code
through every iteration performed by the macro preprocessor, and the
configure preprocessor, so that you can see the transformation of
every line of code as it is made, with a record of each, either
through meta data which augments the original through to the final
form, or by literal hard copies of the before-and-after files with
the list of changes per line as by an xml document, for example.

> configure() sounds like a great way to inject malware into source
> code without people noticing.  At least with #define, you can
> only replace one identifier, and if you are wondering if it is
> replaced, you have that identifier to search for elsewhere in the 
> code.

It is done at compile time.  If someone is compiling source code
and the configure script has malware in it ... sure.  The same is
possible today by downloading source code and running a ./configure
script.  The configure ability I'm talking about, like ./configure,
is not run on a person's machine at startup of the executable, but
rather is done only at compile time.

> >      struct SConfig
> >      {
> >           int    switchc;     // Number of command-line switches
> >           char** switchv;     // Access to each switch
> > 
> >           int    sourcecodec; // Number of source code files
> >           char** sourcecodev; // Access to each source code name
> > 
> >           int    includec;    // Number of include files
> >           char** includev;    // Access to each include file
> > 
> >           int    envc;        // Number of environment constants
> >           char** envv;        // Access to environment constants
> >           // Note:  These would be things like:
> >           //            "os=linux"
> >           //            "cpu=i686"
> >           //            "machine=rickh"
> >           //            "compiler=gcc-4.8.0"
> > 
> >           // Et cetera
> >      };
> 
> You have now thrown the idea of cross-compilation into the dumpster.

Nope.  Cross-compilation is possible.  I have an example earlier in
this thread where I generate for ARM, i686, and x86-64 from a single
for (;;) loop by changing those settings dynamically through configure.

> Also, isn't this supposed to be a pre-processor for a (single)
> compilation?  (That is, it doesn't do an entire executable or library
> all at once.) A single compilation probably has *ONE* source (.c)
> file, and a few .h files.

I introduce the compile; command, which allows the configure script
to physically compile code.

I think you should re-read what I've written in this thread so far
and then I will proceed.

> Also, since command-line switches are *NOT* standardized, how is
> the program supposed to make productive use of this information?
> The number of include files in any given compilation is *NOT* necessarily
> the same for each source file.  It's great for an Obfuscated C
> contest where only the *FIRST* file on the command line generates
> any code.
> 
> I suppose this is an attempt to make sure that the object generated is
> different for every machine that ever existed.  Of course __TIME__ and
> __DATE__ do that, and to a lesser extent __FILE__ does that, but
> the possibilities here are greatly multiplied.
> 
> >      void configure(struct SConfig* c)
> >      {
> >          // Reference to c-> item would be available
> > 
> >          // Commands would be available to search envv options:
> >          if (isFound(c->env, "os", "linux") {
> >              // Specific code for Linux goes here
> >          } else if (isFound(c->env, "os", "windows") {
> >              // Specific code for Windows goes here
> >          }
> > 
> >          // Et cetera
> >      }
> > 
> 
> One idea I DON'T see in this proposal is #ifinclude, and I don't see
> a way to simulate it.  
> 
> #ifinclude <getopt.h>
> ... code if you found <getopt.h> ...
> #else
> ... code if <getopt.h> wasn't found or is otherwise unavailable ...
> #endif
> 
> This could replace a lot of work done by GNU "configure" scripts
> with HAVE_MALLOC_H, etc., variables used to indicate which include
> files are available.

Best regards,
Rick C. Hodgin

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

#68061

Rick C. Hodgin wrote:
>
> In the source code you could replace those #if..#endif blocks with
> the new token form, like $this$;.  As such, the token takes on the
> name of its operation, and then because you see the $token$; form,
> you know to look in the configure script.  In fact, because this
> new ability is a new ability, it should have a closely coupled
> relationship to an API available for a text editor, for example,
> which allows for meta data on each source code line that the compiler
> would know about, such as where that $token$; is actually defined,
> in which configure script, which then shows you that content nearby.
>
> The same is available with #if token1 == token2 on the token1 and
> token2 names, but it's not quite the same.  In source code you could
> have this:
>
>      void my_function(void)
>      {
>      #if PLATFORM == WINDOWS
>          // Code goes here
>      #elif PLATFORM == LINUX
>          // Code goes here
>      #else
>          // Fallback code goes here
>      #endif
>
>           // Other code
>      }
>
> ....replaced with something which conveys what it's doing:
>
>      void my_function(void)
>      {
>          $initialization_code_for_my_function$;
>
>           // Other code
>      }

How is that different (or an any way better) than splitting 
my_function() into generic and platform specific parts?

>      inject before myFunction() = { /* New code before myFunction()
>                                        goes here */ };
>
>      replace myFunction() = { /* The *NEW* myFunction() is used by
>                                  the code in this block */ };
>
> These two will inject code after the variable declarations, and
> before the first line of non-variable-declaration source code (for
> prepend), and after the last line of code before the closing } (for
> append).

This is horrible.  You can change the behaviour of tested code in 
unexpected ways.

-- 
Ian Collins

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

#68063

On Saturday, August 22, 2015 at 7:13:57 PM UTC-4, Ian Collins wrote:
> Rick C. Hodgin wrote:
> >
> > In the source code you could replace those #if..#endif blocks with
> > the new token form, like $this$;.  As such, the token takes on the
> > name of its operation, and then because you see the $token$; form,
> > you know to look in the configure script.  In fact, because this
> > new ability is a new ability, it should have a closely coupled
> > relationship to an API available for a text editor, for example,
> > which allows for meta data on each source code line that the compiler
> > would know about, such as where that $token$; is actually defined,
> > in which configure script, which then shows you that content nearby.
> >
> > The same is available with #if token1 == token2 on the token1 and
> > token2 names, but it's not quite the same.  In source code you could
> > have this:
> >
> >      void my_function(void)
> >      {
> >      #if PLATFORM == WINDOWS
> >          // Code goes here
> >      #elif PLATFORM == LINUX
> >          // Code goes here
> >      #else
> >          // Fallback code goes here
> >      #endif
> >
> >           // Other code
> >      }
> >
> > ....replaced with something which conveys what it's doing:
> >
> >      void my_function(void)
> >      {
> >          $initialization_code_for_my_function$;
> >
> >           // Other code
> >      }
> 
> How is that different (or an any way better) than splitting 
> my_function() into generic and platform specific parts?
> 
> >      inject before myFunction() = { /* New code before myFunction()
> >                                        goes here */ };
> >
> >      replace myFunction() = { /* The *NEW* myFunction() is used by
> >                                  the code in this block */ };
> >
> > These two will inject code after the variable declarations, and
> > before the first line of non-variable-declaration source code (for
> > prepend), and after the last line of code before the closing } (for
> > append).
> 
> This is horrible.  You can change the behaviour of tested code in 
> unexpected ways.

I can only envision it being done by platform consideration, such as
you leave the original function in source code which operates on most
POSIX systems, but on these two peculiar ones which are not fully
POSIX compliant, you replace them out with the alternative, for
example.

Best regards,
Rick C. Hodgin

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

#68064

On Saturday, August 22, 2015 at 7:19:30 PM UTC-4, Rick C. Hodgin wrote:
> On Saturday, August 22, 2015 at 7:13:57 PM UTC-4, Ian Collins wrote:
> > Rick C. Hodgin wrote:
> > >
> > > In the source code you could replace those #if..#endif blocks with
> > > the new token form, like $this$;.  As such, the token takes on the
> > > name of its operation, and then because you see the $token$; form,
> > > you know to look in the configure script.  In fact, because this
> > > new ability is a new ability, it should have a closely coupled
> > > relationship to an API available for a text editor, for example,
> > > which allows for meta data on each source code line that the compiler
> > > would know about, such as where that $token$; is actually defined,
> > > in which configure script, which then shows you that content nearby.
> > >
> > > The same is available with #if token1 == token2 on the token1 and
> > > token2 names, but it's not quite the same.  In source code you could
> > > have this:
> > >
> > >      void my_function(void)
> > >      {
> > >      #if PLATFORM == WINDOWS
> > >          // Code goes here
> > >      #elif PLATFORM == LINUX
> > >          // Code goes here
> > >      #else
> > >          // Fallback code goes here
> > >      #endif
> > >
> > >           // Other code
> > >      }
> > >
> > > ....replaced with something which conveys what it's doing:
> > >
> > >      void my_function(void)
> > >      {
> > >          $initialization_code_for_my_function$;
> > >
> > >           // Other code
> > >      }
> > 
> > How is that different (or an any way better) than splitting 
> > my_function() into generic and platform specific parts?
> > 
> > >      inject before myFunction() = { /* New code before myFunction()
> > >                                        goes here */ };
> > >
> > >      replace myFunction() = { /* The *NEW* myFunction() is used by
> > >                                  the code in this block */ };
> > >
> > > These two will inject code after the variable declarations, and
> > > before the first line of non-variable-declaration source code (for
> > > prepend), and after the last line of code before the closing } (for
> > > append).
> > 
> > This is horrible.  You can change the behaviour of tested code in 
> > unexpected ways.
> 
> I can only envision it being done by platform consideration, such as
> you leave the original function in source code which operates on most
> POSIX systems, but on these two peculiar ones which are not fully
> POSIX compliant, you replace them out with the alternative, for
> example.

In addition, because this is a compiler feature, the text editor would
be able to show the original source code, along with its translated
form through the configure steps, side-by-side so you can see the
compiled changes of your code without having to sift through pages of
#if..#elif..#endif blocks, etc.  Just one function, which is then
shown changed based on various configuration settings which can be
selected in the editor which supports this ability, to see how it
would look in each form, with immediate feedback while developing.

You can also switch to the other forms which are defined for replacement
in that function, and edit them all there without going vertically as
by many source code lines, but actually editing it in place by selecting
the particular version for the target, seeing the code as it is without
the #if..#endif clutter, etc., something which I find makes source code
difficult to read without a text editor which provides syntax highlight
coloring based on an examination of the tests.  Since this compiler
ability would be exposed through an API, it would allow the text editor
to know things about that code that it wouldn't otherwise know, and to
give the user a selection to see it as if it were on Linux, or Windows,
or on CPU x, or CPU y, or whatever other combinations there are.  And
the editor could also sequence them one after the other, or side-by-side
for a more traditional examination.

Best regards,
Rick C. Hodgin

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

#68075

On 8/22/15 7:29 PM, Rick C. Hodgin wrote:

> In addition, because this is a compiler feature, the text editor would
> be able to show the original source code, along with its translated
> form through the configure steps, side-by-side so you can see the
> compiled changes of your code without having to sift through pages of
> #if..#elif..#endif blocks, etc.  Just one function, which is then
> shown changed based on various configuration settings which can be
> selected in the editor which supports this ability, to see how it
> would look in each form, with immediate feedback while developing.

The only way a text editor would know how to convert the configure steps 
is if it contains a compiler or is tightly linked to a compiler. (The 
described config step sounds like it would be hard for the editor to 
process with much less).

There are many editor which understand enough of the C language to be 
able to mostly determine which #if/#elif/#else sections are active to 
control the highlighting/collapsing to mark active code.

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

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

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

csiph-web