On Friday, 13 May 2022 at 17:35:35 UTC, IGotD- wrote:
> On Friday, 13 May 2022 at 17:27:01 UTC, H. S. Teoh wrote:
>>
>> As for #define'd manifest constants, wouldn't it just be a matter of adding a separate pass over the .h file to extract #define's that look like they can be transformed into enum constants?  Shouldn't be *that* hard to do, in theory anyway.
>>
>
> There must be a similar way as with C compilers (the -D command line option) to inject defines. The D compiler must add this so that import C constants can be defined at the command line otherwise we have that extra custom build step again.

Most likely the D compiler will provide some way to pass arbitrary command-line options to the C preprocessor, just like it does for the linker (-Lwhatever).

On Fri, May 13, 2022 at 05:35:35PM +0000, IGotD- via Digitalmars-d wrote:
> On Friday, 13 May 2022 at 17:27:01 UTC, H. S. Teoh wrote:
> > 
> > As for #define'd manifest constants, wouldn't it just be a matter of adding a separate pass over the .h file to extract #define's that look like they can be transformed into enum constants?  Shouldn't be *that* hard to do, in theory anyway.
> > 
> 
> There must be a similar way as with C compilers (the -D command line option) to inject defines. The D compiler must add this so that import C constants can be defined at the command line otherwise we have that extra custom build step again.

Poor man's workaround:

------ main.d ------
import std;
import __stdin;
void main() {
	writeln(MY_VALUE);
}
--------------------

------ command line ------
echo 'enum MY_VALUE = 123;' | dmd - -run main.d
--------------------------

------ output ------
123
--------------------

;-)

This isn't limited to defining constants; you can inject arbitrary snippets of D code into a compilation this way.  It isn't an *ideal* solution, of course.  But it's possible.

Though unfortunately, I don't think this will work with ImportC. As in, the compiler won't know to invoke the preprocessor with the appropriate -D... flags, so if the .h file depends on some identifier like, e.g., _GNU_SOURCE, being predefined, then it won't work.


T

-- 
Only boring people get bored. -- JM

On 5/13/2022 3:15 AM, forkit wrote:
> Walter, please go and create C->M (C with Modules) instead.

I already did. You can use it today.


> Then make it an international standard.

That's not up to me.

On Friday, 13 May 2022 at 17:35:35 UTC, IGotD- wrote:
> There must be a similar way as with C compilers (the -D command line option) to inject defines. The D compiler must add this so that import C constants can be defined at the command line otherwise we have that extra custom build step again.

Yeah, it will also need import paths and such.

I imagine a command line forwarder is easy enough.

I'd also like for it to be available from inside D - passing structured macros in and getting things out. Though that wouldn't be strictly necessary since you can always ctfe construct a #define string and mixinC it (assuming they do even the basics of mixin C but ive made enough noise it is a prototype wip now)

On 5/13/2022 3:37 AM, IGotD- wrote:
> Thank you and you are saying what I thought from the beginning when I read about import C. Import C is an answer to a question we never asked.

htod, dstep and dpp suggest otherwise.


> Since we don't have a preprocessor

We do:

https://github.com/DigitalMars/dmpp

> and if it ever will exist it will be crippled and unusable.

??

> Basically we have to run a .h file through GCC/Clang in order to run the preprocessor,

It gets run through cpp at the moment, not the C compiler.

> then what is the point of import C if we have to use an external tool to begin with.

D has always required the "associated C compiler" if only because that's where the C standard library it links with, and the external linker, comes from.


> Then we can just use a stand alone tool to convert C .h files to D which is likely to work much better as well.

We already have that tool: htod, dstep and dpp. Ironically, dpp relies on clang.

> Also external tools also opens up the possibility for C++ and other languages translation as well, something that will never happen with import C.

C is how disparate languages communicate with each other. It's the lingua franca of programming languages.


> Now we are several months into import C and Walther claimed it was easy to implement from the beginning which is obviously not true at all. If you look at the bug list, it is just riddled with import C bugs and will be.

Not really. Every compiler has bugs in it.


> Just remove import C, it is pointless and rely on external translation tools instead.

They're good tools, but don't quite get us there.

On Friday, 13 May 2022 at 18:17:06 UTC, Walter Bright wrote:
> htod, dstep and dpp suggest otherwise.

What shortcomings did you see in those, and how does ImportC solve them?

> They're good tools, but don't quite get us there.

In what way? How does ImportC get where they don't?

On 5/13/2022 5:45 AM, IGotD- wrote:
> Import C is obsoloete before it is ready (wich it will never be). The limitations of import C will force people to conversion tools and/or manual conversion. C .h files are in general full of "clever" preprocessor tricks that never will be supported by import C.

Preprocessor metaprogramming macros will never be directly available to D. However, they work with ImportC, because the preprocessor runs on the ImportC code to produce C.

htod, dstep, and dpp also will simply ignore metaprogramming macros.


> import C feels like one of those corporate blunders where the management throws in resources into something that will hardly sell while it was obvious from the very beginning it was a bad idea.

My whole career is based on doing things everyone tells me are stupid :-)

On 5/13/2022 6:04 AM, Paolo Invernizzi wrote:
> One thing I've not understood is why Walter decided not to integrate warp ... I don't remember a clear motivation of this choice

The reason is all the predefined macros that appear in each of cpp, cl, and sppn. Around 500 for cpp, largely undocumented, and sensitive to which version of cpp one is running and what command line switches are present.

Keeping that list of predefined macros current with every variation of cpp, cl and sppn would be a constant maintenance nightmare.

On 5/13/2022 6:12 AM, Adam D Ruppe wrote:
> But you can still use the system preprocessor. There's an open PR to just shell out to it.

It was merged yesterday.

> Just this still leaves it less capable than dstep already is due to no work with the defined constants.

I know. But that is not a difficult problem.

> This is why I wrote this mixin c proposal in last October.

Feel free to post it here.

On Fri, May 13, 2022 at 06:22:08PM +0000, Adam D Ruppe via Digitalmars-d wrote:
> On Friday, 13 May 2022 at 18:17:06 UTC, Walter Bright wrote:
> > htod, dstep and dpp suggest otherwise.
> 
> What shortcomings did you see in those, and how does ImportC solve them?

I think somebody has mentioned: all of these require an extra build step.

Personally, I don't think it's a big deal, but then again I use a real build system as opposed to crippled walled gardens (*ahem* *cough* not naming names here), so hey.  In any case, if you could just `import "freetype/freetype.h";` and have it Just Work(tm) without further ado, that would make C integration even more accessible than ever, esp to people with a phobia of using/modifying a real build system.


> > They're good tools, but don't quite get us there.
> 
> In what way? How does ImportC get where they don't?

Assuming that ImportC overcomes its current limitations, the difference is:

htod/dstep/dpp:
- Edit dub.json / makefile / whatever
- Create rule to run htod/dstep/dpp on library.h to create a library.di
  or library.d.
- Don't forget to add `-L-llibrary` to linker flags.
- `import library;'.

ImportC (assuming limitations are fixed):
- `import library;`.

It's a matter of removing the speedbumps on the road so that there's less friction to interfacing with C.


T

-- 
Your inconsistency is the only consistent thing about you! -- KD