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

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

'Amalgamated' source code

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

Contents

  'Amalgamated' source code BartC <bc@freeuk.com> - 2017-01-03 15:14 +0000
    Re: 'Amalgamated' source code Thiago Adams <thiago.adams@gmail.com> - 2017-01-03 08:47 -0800
      Re: 'Amalgamated' source code BartC <bc@freeuk.com> - 2017-01-03 19:47 +0000
        Re: 'Amalgamated' source code Thiago Adams <thiago.adams@gmail.com> - 2017-01-03 12:48 -0800
          Re: 'Amalgamated' source code BartC <bc@freeuk.com> - 2017-01-03 21:36 +0000
            Re: 'Amalgamated' source code Thiago Adams <thiago.adams@gmail.com> - 2017-01-03 16:01 -0800
              Re: 'Amalgamated' source code Keith Thompson <kst-u@mib.org> - 2017-01-03 16:26 -0800
                Re: 'Amalgamated' source code Thiago Adams <thiago.adams@gmail.com> - 2017-01-03 18:00 -0800
                  Re: 'Amalgamated' source code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-04 03:34 +0000
                    Re: 'Amalgamated' source code Thiago Adams <thiago.adams@gmail.com> - 2017-01-04 03:31 -0800
                      Re: 'Amalgamated' source code BartC <bc@freeuk.com> - 2017-01-04 12:03 +0000
                        Re: 'Amalgamated' source code Thiago Adams <thiago.adams@gmail.com> - 2017-01-04 05:00 -0800
                          Re: 'Amalgamated' source code Thiago Adams <thiago.adams@gmail.com> - 2017-01-05 02:38 -0800
                            Re: 'Amalgamated' source code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-05 14:28 +0000
                              Re: 'Amalgamated' source code supercat@casperkitty.com - 2017-01-05 08:20 -0800
                                Re: 'Amalgamated' source code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-05 17:05 +0000
                                  Re: 'Amalgamated' source code supercat@casperkitty.com - 2017-01-05 10:11 -0800
                                    Re: 'Amalgamated' source code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-05 19:46 +0000
                                      Re: 'Amalgamated' source code Thiago Adams <thiago.adams@gmail.com> - 2017-01-05 12:15 -0800
                                        Re: 'Amalgamated' source code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-05 21:54 +0000
                              Re: 'Amalgamated' source code BartC <bc@freeuk.com> - 2017-01-05 17:40 +0000
                                Re: 'Amalgamated' source code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-05 19:33 +0000
              Re: 'Amalgamated' source code BartC <bc@freeuk.com> - 2017-01-04 10:53 +0000
            Re: 'Amalgamated' source code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-04 01:51 +0000
          Re: 'Amalgamated' source code BartC <bc@freeuk.com> - 2017-01-04 11:54 +0000
            Re: 'Amalgamated' source code Thiago Adams <thiago.adams@gmail.com> - 2017-01-04 05:57 -0800
              Re: 'Amalgamated' source code BartC <bc@freeuk.com> - 2017-01-04 14:20 +0000
              Re: 'Amalgamated' source code BartC <bc@freeuk.com> - 2017-01-04 15:07 +0000
                Re: 'Amalgamated' source code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-04 15:34 +0000
                  Re: 'Amalgamated' source code Thiago Adams <thiago.adams@gmail.com> - 2017-01-04 08:03 -0800
                    Re: 'Amalgamated' source code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-04 17:09 +0000
                  Re: 'Amalgamated' source code bart4858@gmail.com - 2017-01-04 08:54 -0800
                    Re: 'Amalgamated' source code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-04 17:22 +0000
                Re: 'Amalgamated' source code Thiago Adams <thiago.adams@gmail.com> - 2017-01-04 07:55 -0800
                  Re: 'Amalgamated' source code BartC <bc@freeuk.com> - 2017-01-05 18:04 +0000
                    Re: 'Amalgamated' source code Thiago Adams <thiago.adams@gmail.com> - 2017-01-05 11:50 -0800
    Re: 'Amalgamated' source code Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-01-04 16:29 +0000
      Re: 'Amalgamated' source code bart4858@gmail.com - 2017-01-04 09:15 -0800
        Re: 'Amalgamated' source code Ian Collins <ian-news@hotmail.com> - 2017-01-05 08:33 +1300
          Re: 'Amalgamated' source code BartC <bc@freeuk.com> - 2017-01-04 20:26 +0000
            Re: 'Amalgamated' source code supercat@casperkitty.com - 2017-01-04 13:09 -0800
            Re: 'Amalgamated' source code Ian Collins <ian-news@hotmail.com> - 2017-01-05 10:21 +1300
              Re: 'Amalgamated' source code supercat@casperkitty.com - 2017-01-04 13:51 -0800
              Re: 'Amalgamated' source code BartC <bc@freeuk.com> - 2017-01-04 22:02 +0000
                Re: 'Amalgamated' source code Ian Collins <ian-news@hotmail.com> - 2017-01-05 11:15 +1300
        Re: 'Amalgamated' source code Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-01-07 06:38 +0000
          Re: 'Amalgamated' source code BartC <bc@freeuk.com> - 2017-01-07 11:35 +0000
      Re: 'Amalgamated' source code supercat@casperkitty.com - 2017-01-04 09:53 -0800
      Re: 'Amalgamated' source code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-04 11:50 -0800
      Re: 'Amalgamated' source code raltbos@xs4all.nl (Richard Bos) - 2017-01-10 01:34 +0000
        Re: 'Amalgamated' source code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-10 01:59 -0800
        Re: 'Amalgamated' source code Les Cargill <lcargill99@comcast.com> - 2017-01-10 06:55 -0600
        Re: 'Amalgamated' source code Richard Heathfield <rjh@cpax.org.uk> - 2017-01-10 14:48 +0000
    Re: 'Amalgamated' source code Thiago Adams <thiago.adams@gmail.com> - 2017-04-26 07:17 -0700

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

#101188

On 05/01/2017 14:28, Ben Bacarisse wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:
> <snip>
>> I did one more sample to see what happens:
>>
>> #define M(a) X##a
>> #define M2(a, b) #a a b
>>
>> M2(  M ( 1), M(1))
>>
>> VC++ preprocessor output:
>>
>> "M ( 1)" X1 X1
>>
>> The same argument 'a' for macro can or not be expanded before
>> the macro invocation.
>>
>> Today I keep a map "parameter-name:a" - > "expanded:X1"
>>
>> To fix my preprocessor I will keep both:
>>
>>   "parameter-name:a" - > ["expanded:X1", "not expanded:M ( 1)"]
>>
>> and use the appropriated value depending on #a or a.
>
> That seems like a very odd way to do it.  Have you read what the C
> standard says about macro expansion?  It explains the algorithm quite
> well, in my option.

I couldn't make head or tail of it (6.10.3.1):

"A parameter in the replacement list, unless ... is replaced by the 
corresponding argument after all macros contained therein have been 
expanded. Before being substituted, each argument’s preprocessing tokens 
are completely macro replaced as if they formed the rest of the 
preprocessing file; no other preprocessing tokens are available."

What does the second sentence mean; is it just restating what happens in 
the first? And that's not all of it; the process continues in 6.10.3.4.

Here's how the gnu CPP docs explain it; I think this covers all of it 
apart from # and ##:

"All arguments to a macro are completely macro-expanded before they are 
substituted into the macro body. After substitution, the complete text 
is scanned again for macros to expand, including the arguments."

Of course I will have to try out this second scheme to see if handles 
all the tricky examples.

-- 
bartc

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

#101195

BartC <bc@freeuk.com> writes:

> On 05/01/2017 14:28, Ben Bacarisse wrote:
>> Thiago Adams <thiago.adams@gmail.com> writes:
>> <snip>
>>> I did one more sample to see what happens:
>>>
>>> #define M(a) X##a
>>> #define M2(a, b) #a a b
>>>
>>> M2(  M ( 1), M(1))
>>>
>>> VC++ preprocessor output:
>>>
>>> "M ( 1)" X1 X1
>>>
>>> The same argument 'a' for macro can or not be expanded before
>>> the macro invocation.
>>>
>>> Today I keep a map "parameter-name:a" - > "expanded:X1"
>>>
>>> To fix my preprocessor I will keep both:
>>>
>>>   "parameter-name:a" - > ["expanded:X1", "not expanded:M ( 1)"]
>>>
>>> and use the appropriated value depending on #a or a.
>>
>> That seems like a very odd way to do it.  Have you read what the C
>> standard says about macro expansion?  It explains the algorithm quite
>> well, in my option.
>
> I couldn't make head or tail of it (6.10.3.1):
>
> "A parameter in the replacement list, unless ... is replaced by the
> corresponding argument after all macros contained therein have been
> expanded. Before being substituted, each argument’s preprocessing
> tokens are completely macro replaced as if they formed the rest of the
> preprocessing file; no other preprocessing tokens are available."
>
> What does the second sentence mean; is it just restating what happens
> in the first?

It says a bit more than the first.  In particular it says the each
argument's token list is treated separately and like a file on it's own.
Maybe you never thought otherwise but perhaps that's been the source of
some confusion in that past.

> And that's not all of it; the process continues in
> 6.10.3.4.
>
> Here's how the gnu CPP docs explain it; I think this covers all of it
> apart from # and ##:

But # and ## are the problem here.  It's much easier to explain
expansion while ignoring or glossing over # and ##.

> "All arguments to a macro are completely macro-expanded before they
> are substituted into the macro body. After substitution, the complete
> text is scanned again for macros to expand, including the arguments."
>
> Of course I will have to try out this second scheme to see if handles
> all the tricky examples.

It's not hard to describe in broad terms.  The problem is saying exactly
what happens and in what order.  If the gcc docs helps then I think
that's great.

-- 
Ben.

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

#101083

On 04/01/2017 00:01, Thiago Adams wrote:
> On Tuesday, January 3, 2017 at 7:36:53 PM UTC-2, Bart wrote:

>> But retaining a C output option has several benefits, including
>> converting multi-module apps to single-file C source code, and
>> translating experimental language extensions to standard C.
>
> If you do language extensions for instance I think the users would like to see one "natural" code.
> This is almost like a code format, where you must keep comments and macro without expansion.
> For instance, if the programmer use #ifdef then the code extension should be always processed for each #ifdef option. If the generated C code were "natural" it could include these #ifdefs. Also for debbuging. And instead of having one big file you could keep the same file logic that user choose. As an option the compiler could generate the module one-file only.
>
> Today I can read one translation unit and generate the AST.  After that I can generate C code again.
> If I do that, the generated code will contain all the definitions from system includes for instance, and no macros.
> For each declaration I have the source file, so I can ignore declaration from extern code. Doing this the generated code is small but all the macros and #ifs disappears  (expanded).
>
> I think I can keep comments inside the AST as something appended on each ast node.
>
> for macros I dont have idea what to do.

Usually I don't need to see the intermediate C code, except when 
debugging, or passing it off to someone else as "C".

Then it would be nice to keep intermediate C code readable, but there 
are limits to what can be done easily.

I found retaining comments quite tricky, especially if the block 
structure on output can be modified.

  /*C0*/ if /*C1*/ (/*C2*/a==/*C3*/b) {  // C4
/*C5*/  S1; //C6
  } //C7
  else /*C8*/ { ....

Plus, as you say, comments inside macro invocations. When you add in 
extensions, you can have comments inside input source constructs that 
have no direct equivalent in the output; what happens to the comments?

But it can't be impossible as there appear to be refactoring tools that 
presumably retain comments.

-- 
Bartc

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

#101073

BartC <bc@freeuk.com> writes:
<snip>
> DEF_FORMAT_ATTRIBUTE(PRINTF,1,1_0)
>
> The token '1_0' appears. It starts as a number but presumably must be
> treated as alphanumeric.

It's a pp-number (they came up recently in another thread).  If it gets
used as a number it will result in a error.  Likewise if it gets used as
an identifier.

The syntax for pp-token breaks the input up into tokens using very
simple rules.  These are shuffled about by the pre-processor and the
tokens are sometimes interpreted as having a meaning (as, for example,
and identifier or a number).  In the example you gave, the token 1_0 is
simply glued onto another token to make an identifier.

<snip>
-- 
Ben.

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

#101086

On 03/01/2017 20:48, Thiago Adams wrote:
> On Tuesday, January 3, 2017 at 5:47:24 PM UTC-2, Bart wrote:

>> (I'm the middle of one at the minute. Most online refs on writing
>> compilers tend to ignore this piffling little obstacle that you have to
>> overcome first!)
>
> I didn't find a good references. I did it completely wrong at the beginning.
> This is an sample from C standard that shows me my first mistakes.
>
> #define hash_hash # ## #
> #define mkstr(a) # a
> #define in_between(a) mkstr(a)
> #define join(c, d) in_between(c hash_hash d)
> char p[] = join(x, y);
> // equivalent to
> // char p[] = "x ## y";

I tried this on the handful of compilers I have.

One produced the string "x y", another "xy", a third "x##y", the others 
the correct "x ## y".

Another example in the C standard was something like this:

#define EMPTY
EMPTY #include "dummy.h"

The #include doesn't count as a proper directive because it's not at the 
start of a line, but will be after EMPTY is expanded (to nothing). One 
compiler however tried to include "dummy.h"!

But that hash_hash example looks evil. I think I will have to play 
around with experimental macro expanding routines in a scripting 
language otherwise this will take ages to get right. (I'm also trying to 
keep tokenising and preprocessing extremely fast.)

-- 
Bartc

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

#101091

On Wednesday, January 4, 2017 at 9:54:53 AM UTC-2, Bart wrote:
[...]
> But that hash_hash example looks evil. I think I will have to play 
> around with experimental macro expanding routines in a scripting 
> language otherwise this will take ages to get right. (I'm also trying to 
> keep tokenising and preprocessing extremely fast.)

I have created a project on github with my preprocessor
https://github.com/thradams/cpreprocessor

It reads a file and print preprocessed text into console.

I just remove the code that does the expression evaluation of 
#if.

This project could be used to do the amalgamation tool as well 
leaving just #include part and removing #ifdef etc...

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

#101092

On 04/01/2017 13:57, Thiago Adams wrote:
> On Wednesday, January 4, 2017 at 9:54:53 AM UTC-2, Bart wrote:
> [...]
>> But that hash_hash example looks evil. I think I will have to play
>> around with experimental macro expanding routines in a scripting
>> language otherwise this will take ages to get right. (I'm also trying to
>> keep tokenising and preprocessing extremely fast.)
>
> I have created a project on github with my preprocessor
> https://github.com/thradams/cpreprocessor

(That immediately brings up something else I hadn't realised:

   #include "..\Base\Array.h"

the string that follows #include isn't a regular C string, but a special 
kind of token invented just for this directive.

Now programs need to process Q strings as well as normal strings.)

-- 
Bartc

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

#101094

On 04/01/2017 13:57, Thiago Adams wrote:
> On Wednesday, January 4, 2017 at 9:54:53 AM UTC-2, Bart wrote:
> [...]
>> But that hash_hash example looks evil. I think I will have to play
>> around with experimental macro expanding routines in a scripting
>> language otherwise this will take ages to get right. (I'm also trying to
>> keep tokenising and preprocessing extremely fast.)
>
> I have created a project on github with my preprocessor
> https://github.com/thradams/cpreprocessor
>
> It reads a file and print preprocessed text into console.

OK, I've downloaded the files, and it compiles and builds (because there 
is no makefile/configure nonsense!), and will be playing with it 
shortly. (Note it crashes if the input file doesn't exist [built with 
gcc -m32 on Windows])

But there was one funny thing on line 44 of stream.c:

            //Ve se tem pontos ..\
            const char* p = &path[2];

the \ at the end of the // comment means the next line is part of the 
comment. It means that gcc for one can't see the declaration. If you're 
not aware of that, maybe your cpp isn't either!)

-- 
Bartc

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

#101099

BartC <bc@freeuk.com> writes:

> On 04/01/2017 13:57, Thiago Adams wrote:
>> On Wednesday, January 4, 2017 at 9:54:53 AM UTC-2, Bart wrote:
>> [...]
>>> But that hash_hash example looks evil. I think I will have to play
>>> around with experimental macro expanding routines in a scripting
>>> language otherwise this will take ages to get right. (I'm also trying to
>>> keep tokenising and preprocessing extremely fast.)
>>
>> I have created a project on github with my preprocessor
>> https://github.com/thradams/cpreprocessor
>>
>> It reads a file and print preprocessed text into console.
>
> OK, I've downloaded the files, and it compiles and builds (because
> there is no makefile/configure nonsense!),

That may be why it won't compile on my system.  You can avoid what you
call "configure nonsense" when there is nothing that needs to be
configured.  (By the way, I'm not complaining -- it's fine to write a
Windows only program.)

<snip>
-- 
Ben.

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

#101103

On Wednesday, January 4, 2017 at 1:34:28 PM UTC-2, Ben Bacarisse wrote:
> BartC  writes:
> 
> > On 04/01/2017 13:57, Thiago Adams wrote:
> >> On Wednesday, January 4, 2017 at 9:54:53 AM UTC-2, Bart wrote:
> >> [...]
> >>> But that hash_hash example looks evil. I think I will have to play
> >>> around with experimental macro expanding routines in a scripting
> >>> language otherwise this will take ages to get right. (I'm also trying to
> >>> keep tokenising and preprocessing extremely fast.)
> >>
> >> I have created a project on github with my preprocessor
> >> https://github.com/thradams/cpreprocessor
> >>
> >> It reads a file and print preprocessed text into console.
> >
> > OK, I've downloaded the files, and it compiles and builds (because
> > there is no makefile/configure nonsense!),
> 
> That may be why it won't compile on my system.  You can avoid what you
> call "configure nonsense" when there is nothing that needs to be
> configured.  (By the way, I'm not complaining -- it's fine to write a
> Windows only program.)

The dependency with Windows OS is at

Stream.c
#include <Shlwapi.h>

I need an alternative to

GetFullPathName (https://msdn.microsoft.com/en-us/library/windows/desktop/aa364963(v=vs.85).aspx)

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

#101110

Thiago Adams <thiago.adams@gmail.com> writes:

> On Wednesday, January 4, 2017 at 1:34:28 PM UTC-2, Ben Bacarisse wrote:
>> BartC  writes:
>> 
>> > On 04/01/2017 13:57, Thiago Adams wrote:
>> >> On Wednesday, January 4, 2017 at 9:54:53 AM UTC-2, Bart wrote:
>> >> [...]
>> >>> But that hash_hash example looks evil. I think I will have to play
>> >>> around with experimental macro expanding routines in a scripting
>> >>> language otherwise this will take ages to get right. (I'm also trying to
>> >>> keep tokenising and preprocessing extremely fast.)
>> >>
>> >> I have created a project on github with my preprocessor
>> >> https://github.com/thradams/cpreprocessor
>> >>
>> >> It reads a file and print preprocessed text into console.
>> >
>> > OK, I've downloaded the files, and it compiles and builds (because
>> > there is no makefile/configure nonsense!),
>> 
>> That may be why it won't compile on my system.  You can avoid what you
>> call "configure nonsense" when there is nothing that needs to be
>> configured.  (By the way, I'm not complaining -- it's fine to write a
>> Windows only program.)
>
> The dependency with Windows OS is at
>
> Stream.c
> #include <Shlwapi.h>

If there's only one then switching to / in include file names might
make the program compile in Linux but I think you also have some literal
\s in the code used to make pathnames.

> I need an alternative to
>
> GetFullPathName
> (https://msdn.microsoft.com/en-us/library/windows/desktop/aa364963(v=vs.85).aspx)

That would need to be written for Linux and/or POSIX.  I'm not sure
exactly what it does but it does not sound hard to do.  Look at
realpath(3) (that means realpath in section 3 of the Linux/Unix manual)
as the starting point.

-- 
Ben.

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

#101108

On Wednesday, 4 January 2017 15:34:28 UTC, Ben Bacarisse  wrote:
> BartC <bc@freeuk.com> writes:
> 

> > OK, I've downloaded the files, and it compiles and builds (because
> > there is no makefile/configure nonsense!),
> 
> That may be why it won't compile on my system.  You can avoid what you
> call "configure nonsense" when there is nothing that needs to be
> configured.  (By the way, I'm not complaining -- it's fine to write a
> Windows only program.)

If you want to run it, and you have 'wine', then here's a Windows 32-bit binary:

https://github.com/bartg/langs/blob/master/cpp.exe

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

#101113

bart4858@gmail.com writes:

> On Wednesday, 4 January 2017 15:34:28 UTC, Ben Bacarisse  wrote:
>> BartC <bc@freeuk.com> writes:
>> 
>
>> > OK, I've downloaded the files, and it compiles and builds (because
>> > there is no makefile/configure nonsense!),
>> 
>> That may be why it won't compile on my system.  You can avoid what you
>> call "configure nonsense" when there is nothing that needs to be
>> configured.  (By the way, I'm not complaining -- it's fine to write a
>> Windows only program.)
>
> If you want to run it, and you have 'wine', then here's a Windows 32-bit binary:
>
> https://github.com/bartg/langs/blob/master/cpp.exe

Thanks, but a binary like that is likely to get stale very quickly.  It
would e useful if I needed the tool, but testing you need an up-to-date
binary.

-- 
Ben.

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

#101102

On Wednesday, January 4, 2017 at 1:07:56 PM UTC-2, Bart wrote:
> On 04/01/2017 13:57, Thiago Adams wrote:
> > On Wednesday, January 4, 2017 at 9:54:53 AM UTC-2, Bart wrote:
> > [...]
> >> But that hash_hash example looks evil. I think I will have to play
> >> around with experimental macro expanding routines in a scripting
> >> language otherwise this will take ages to get right. (I'm also trying to
> >> keep tokenising and preprocessing extremely fast.)
> >
> > I have created a project on github with my preprocessor
> > https://github.com/thradams/cpreprocessor
> >
> > It reads a file and print preprocessed text into console.
> 
> OK, I've downloaded the files, and it compiles and builds (because there 
> is no makefile/configure nonsense!), and will be playing with it 
> shortly. (Note it crashes if the input file doesn't exist [built with 
> gcc -m32 on Windows])
> 
> But there was one funny thing on line 44 of stream.c:
> 
>             //Ve se tem pontos ..\
>             const char* p = &path[2];
> 
> the \ at the end of the // comment means the next line is part of the 
> comment. It means that gcc for one can't see the declaration. If you're 
> not aware of that, maybe your cpp isn't either!)

Thanks, I will fix that.

If more people are interested on this code, we can compile it for other platforms and create other types of build.
Which one do you use/like?

I forgot so say how to specify include directories.

I create a pragma dir for that:


#pragma dir "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include"
#pragma dir "C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt"
#pragma dir "C:\Program Files (x86)\Windows Kits\8.1\Include\um"
#pragma dir "C:\Program Files (x86)\Windows Kits\8.1\Include\shared"

I can include now:

#include <stdio.h>

pragma once was implemented as well.

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

#101189

On 04/01/2017 15:55, Thiago Adams wrote:
> On Wednesday, January 4, 2017 at 1:07:56 PM UTC-2, Bart wrote:

[CPP example app]
> I forgot so say how to specify include directories.

> #pragma dir "C:\Program Files (x86)\Windows Kits\8.1\Include\shared"

Will it handle relative directories? For example:

  #pragma dir ".\include"

and #include <file.h> is found, but file.h contains:

  #include <sys/types>

will it find the sys directory relative to where file.h was, or does it 
need its own pragma?

I've tried processing gcc.c, but I only get 2400 largely blank lines 
before it stops unexpectedly. (And there are 750,000 lines to go!)

I think it does this when it can't find an include file, but there is no 
error message.

-- 
Bartc

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

#101199

On Thursday, January 5, 2017 at 4:04:16 PM UTC-2, Bart wrote:
> On 04/01/2017 15:55, Thiago Adams wrote:
> > On Wednesday, January 4, 2017 at 1:07:56 PM UTC-2, Bart wrote:
> 
> [CPP example app]
> > I forgot so say how to specify include directories.
> 
> > #pragma dir "C:\Program Files (x86)\Windows Kits\8.1\Include\shared"
> 
> Will it handle relative directories? For example:
> 
>   #pragma dir ".\include"

Yes, it should work.

See line 295
https://github.com/thradams/cpreprocessor/blob/master/CPreprocessor/CPreprocessor/Scanner/Scanner.c

https://msdn.microsoft.com/en-us/library/36k2cdd4.aspx

> I've tried processing gcc.c, but I only get 2400 largely blank lines 
> before it stops unexpectedly. (And there are 750,000 lines to go!)

Remember that I removed the expression evaluation! Do you have #if on 
this file? 

Today I use the AST from my parser to do evaluation of #if but I removed 
this code from the cpreprocessor to concentrate on macro expansion problems 
and make an small project.
See line 688.  EvalExpression

All macros that you need for gcc also should be specified.
So in cpreprocessor if you want to expand file1.c you need to create a new file "other.c"

//put your defines here... _DEGUB UNICODE etc..

//add your directories here
#pragma dir "C:\Program Files (x86)\Windows Kits\8.1\Include\shared"
..more..

//finally include the file you want to expand
#include "file1.c"

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

#101105

On Tue, 2017-01-03, BartC wrote:
> Interesting article here on converting large projects into just a few 
> source files:
>
> https://blog.forrestthewoods.com/improving-open-source-with-amalgamation-cf293592c5f4#.jzgq6ppvn

His message seems to be that it's hard to compile software because of
library dependencies.  And (it's not clear how this is related) he
wrote a tool which takes the zlib sources and turn them to one source
file and one header, so he can copy & paste it into his projects.

It doesn't make sense to me, at all.  The problem of building a C
program from N source files was solved by make, 40 years ago.  My best
guess is it's some kind of problem endemic to Windows (which I don't
write code for, but I understand it's not very C-friendly).

Even if he does his things, he has two problems:
- Security, when people find bugs in the libraries he has copy & pasted.
  This has been a problem for zlib in the past (it's small and simple, and people
  have copy & pasted it before).
- Licenses.

> It's something I could do with because I always have trouble compiling 
> open source projects.

On Windows, right?  On Linux (say) it's usually a non-issue, because
everything that's of decent quality is already packaged.

It seems to me the better way would be to submit a working Windows
build system to the project, if they're interested in supporting that
family of platforms.

/Jorgen

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

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

#101112

On Wednesday, 4 January 2017 16:30:04 UTC, Jorgen Grahn  wrote:
> On Tue, 2017-01-03, BartC wrote:
> > Interesting article here on converting large projects into just a few 
> > source files:
> >
> > https://blog.forrestthewoods.com/improving-open-source-with-amalgamation-cf293592c5f4#.jzgq6ppvn
> 
> His message seems to be that it's hard to compile software because of
> library dependencies.  And (it's not clear how this is related) he
> wrote a tool which takes the zlib sources and turn them to one source
> file and one header, so he can copy & paste it into his projects.
> 
> It doesn't make sense to me, at all.  The problem of building a C
> program from N source files was solved by make, 40 years ago.  My best
> guess is it's some kind of problem endemic to Windows (which I don't
> write code for, but I understand it's not very C-friendly).

There are a number of problems, some of which are mentioned, such as that people use different build systems, different compilers, or want to incorporate an open-source project into their own application.

Otherwise it means merging one lot of incomprehensible gibberish (the third party make file) into another (your project), to say nothing of combining two lots of configure scripts. That's assume they are both happy to work with /any/ compiler, or the imported project will work with yours.

Can't you see how INCREDIBLY simple it would become if an import project was just one .h file and one .c file? Then it would also work on anything (subject to OS dependencies; another matter).

> 
> Even if he does his things, he has two problems:
> - Security, when people find bugs in the libraries he has copy & pasted.
>   This has been a problem for zlib in the past (it's small and simple, and people
>   have copy & pasted it before).
> - Licenses.
> 
> > It's something I could do with because I always have trouble compiling 
> > open source projects.
> 
> On Windows, right?  On Linux (say) it's usually a non-issue, because
> everything that's of decent quality is already packaged.

We're talking about building open-source software - from source. Sure, after all the hard work has been done, it can be packaged for easy installation (although I haven't a clue how it's done for Unix. Do you need to build a different binary for each combination of Unix-like distribution and platform?).

> It seems to me the better way would be to submit a working Windows
> build system to the project, if they're interested in supporting that
> family of platforms.

A better intention would be virtually eliminate the concept of 'building'. What problems would you envisage in making a 6-line Hello World program available as source? Very few, if people know how to run a C compiler. The idea is to make any self-contained project just as simple.

Too many developers are too Unix-centric I think, even when claiming to produce software that is 'cross-platform', when it is often nothing of the kind (a point made in the article). By 'cross-platform' they mean you have to install entire Unix sub-systems (such as Cygwin and Msys) then the project will build (which I have tried, and often it doesn't work. And because the failure point is inside a pile of gibberish, I can't fix it).

-- 
bartc

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

#101123

On 01/ 5/17 06:15 AM, bart4858@gmail.com wrote:
> On Wednesday, 4 January 2017 16:30:04 UTC, Jorgen Grahn  wrote:
>> On Tue, 2017-01-03, BartC wrote:
>>> Interesting article here on converting large projects into just a
>>> few source files:
>>>
>>> https://blog.forrestthewoods.com/improving-open-source-with-amalgamation-cf293592c5f4#.jzgq6ppvn
>>
 >> His message seems to be that it's hard to compile software because of
>> library dependencies.  And (it's not clear how this is related) he
>> wrote a tool which takes the zlib sources and turn them to one
>> source file and one header, so he can copy & paste it into his
>> projects.
>>
>> It doesn't make sense to me, at all.  The problem of building a C
>> program from N source files was solved by make, 40 years ago.  My
>> best guess is it's some kind of problem endemic to Windows (which I
>> don't write code for, but I understand it's not very C-friendly).
>
> There are a number of problems, some of which are mentioned, such as
> that people use different build systems, different compilers, or want
> to incorporate an open-source project into their own application.
>
> Otherwise it means merging one lot of incomprehensible gibberish (the
> third party make file) into another (your project), to say nothing of
> combining two lots of configure scripts. That's assume they are both
> happy to work with /any/ compiler, or the imported project will work
> with yours.

The project I'm currently working on incorporates a number of open 
source projects in the build and we use premake and ninja to build 
everything.  There is one premake configuration script we maintain, the 
tools do the rest.

We build for Linux, Windows and embedded arm.

-- 
Ian

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

#101127

On 04/01/2017 19:33, Ian Collins wrote:
> On 01/ 5/17 06:15 AM, bart4858@gmail.com wrote:
>> On Wednesday, 4 January 2017 16:30:04 UTC, Jorgen Grahn  wrote:

>>> It doesn't make sense to me, at all.  The problem of building a C
>>> program from N source files was solved by make, 40 years ago.  My
>>> best guess is it's some kind of problem endemic to Windows (which I
>>> don't write code for, but I understand it's not very C-friendly).
>>
>> There are a number of problems, some of which are mentioned, such as
>> that people use different build systems, different compilers, or want
>> to incorporate an open-source project into their own application.
>>
>> Otherwise it means merging one lot of incomprehensible gibberish (the
>> third party make file) into another (your project), to say nothing of
>> combining two lots of configure scripts. That's assume they are both
>> happy to work with /any/ compiler, or the imported project will work
>> with yours.
>
> The project I'm currently working on incorporates a number of open
> source projects in the build and we use premake and ninja to build
> everything.  There is one premake configuration script we maintain, the
> tools do the rest.
>
> We build for Linux, Windows and embedded arm.

That's great. People should be able to use whatever tools /they/ like, 
for their own work.

Until the code has to be used by someone else. Do you then have to 
stipulate that they acquire the same tools and scripts as you use? How 
do your build scripts interact with theirs?

Apparently SQLite is spread over 100 source files (no doubt in some 
directory structure of the developer's design). I'm sure the internal 
arrangements are very interesting to some people, but for someone who 
just wants to make use of it (and needs to build from source for various 
reasons), they really want it as simple and painless as possible.

For example, my interpreter project consists of about 30 source files, 
and half-a-dozen libraries in its language. It uses some include files 
which are generated by a script in another language and requiring a 
separate interpreter. And those 30 source files aren't even in C yet, 
requiring yet another program to translate them.

But if someone else wants to build it from source, these are the 
instructions in English:

   "Compile the source file pcc.c in 32-bit mode"

Or more specifically (for Linux):

   gcc -O3 pcc.c -opcc -lm -ldl

All those dependencies (which are for *me* to worry about) are eliminated.

Alternatively, I could use your approach and keep all the complexity, 
expose all that structure, and add more complexity and more dependencies 
with extra layers of scripting and required utilities to end up with a 
dog's breakfast of a distribution.

Which version do you think people would rather build? Which is more 
likely to work first time?

And if your tools were really that good, they would be able to do 
exactly what that article is talking about!

-- 
Bartc

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

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

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

csiph-web