[Issue 24444] ImportC: no way to specify where header files "live"

https://issues.dlang.org/show_bug.cgi?id=2 Lance Bachmeier changed: What|Removed |Added CC||la...@lancebachmeier.com --- Comment #3

[Issue 24444] ImportC: no way to specify where header files "live"

https://issues.dlang.org/show_bug.cgi?id=2 --- Comment #2 from Atila Neves --- I see. The -P flag doesn't show up in the man page. --

[Issue 24444] ImportC: no way to specify where header files "live"

https://issues.dlang.org/show_bug.cgi?id=2 Dennis changed: What|Removed |Added CC||dkor...@live.nl Hardware|x86_64

[Issue 24444] ImportC: no way to specify where header files "live"

https://issues.dlang.org/show_bug.cgi?id=2 Atila Neves changed: What|Removed |Added Keywords||ImportC --

[Issue 24444] New: ImportC: no way to specify where header files "live"

https://issues.dlang.org/show_bug.cgi?id=2 Issue ID: 2 Summary: ImportC: no way to specify where header files "live" Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severi

[Issue 6019] Phobos imports in autogenerated .di header files break implicit linking with DLLs

https://issues.dlang.org/show_bug.cgi?id=6019 --- Comment #13 from Walter Bright --- (In reply to Andrej Mitrovic from comment #1) > http://d-programming-language.org/dll.html Now https://wiki.dlang.org/Win32_DLLs_in_D --

[Issue 23547] [REG 2.101-master] C header files have precedent over D modules in imports

https://issues.dlang.org/show_bug.cgi?id=23547 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #4

[Issue 23547] [REG 2.101-master] C header files have precedent over D modules in imports

https://issues.dlang.org/show_bug.cgi?id=23547 --- Comment #3 from Iain Buclaw --- *** Issue 23548 has been marked as a duplicate of this issue. *** --

[Issue 23547] [REG 2.101-master] C header files have precedent over D modules in imports

https://issues.dlang.org/show_bug.cgi?id=23547 Iain Buclaw changed: What|Removed |Added Summary|[REG master] C header files |[REG 2.101-master] C header

[Issue 6019] Phobos imports in autogenerated .di header files break implicit linking with DLLs

https://issues.dlang.org/show_bug.cgi?id=6019 Iain Buclaw changed: What|Removed |Added Priority|P2 |P3 --

[Issue 18589] Windows header files: bcrypt and ncrypt

https://issues.dlang.org/show_bug.cgi?id=18589 Iain Buclaw changed: What|Removed |Added Priority|P1 |P4 --

[Issue 18363] we should autogenerate duplicate “.h” header files in dmd to keep them in sync

https://issues.dlang.org/show_bug.cgi?id=18363 Iain Buclaw changed: What|Removed |Added Priority|P1 |P4 --

[Issue 23547] [REG master] C header files have precedent over D modules in imports

https://issues.dlang.org/show_bug.cgi?id=23547 Iain Buclaw changed: What|Removed |Added Summary|[REG master] C header files |[REG master] C header files

[Issue 23547] [REG master] C header files have precedent over D modules

https://issues.dlang.org/show_bug.cgi?id=23547 Iain Buclaw changed: What|Removed |Added See Also||https://issues.dlang.org/sh

[Issue 23547] [REG master] C header files have precedent over D modules

https://issues.dlang.org/show_bug.cgi?id=23547 Iain Buclaw changed: What|Removed |Added Keywords||ImportC, rejects-valid, |

[Issue 23547] [REG master] C header files have precedent over D modules

https://issues.dlang.org/show_bug.cgi?id=23547 --- Comment #2 from Iain Buclaw --- https://github.com/dlang/dmd/pull/14636 --

[Issue 23547] [REG master] C header files have precedent over D modules

https://issues.dlang.org/show_bug.cgi?id=23547 Iain Buclaw changed: What|Removed |Added CC||ibuc...@gdcproject.org --- Comment #1 from

[Issue 23547] New: [REG master] C header files have precedent over D modules

https://issues.dlang.org/show_bug.cgi?id=23547 Issue ID: 23547 Summary: [REG master] C header files have precedent over D modules Product: D Version: D2 Hardware: All OS: All Status: NEW

[Issue 6019] Phobos imports in autogenerated .di header files break implicit linking with DLLs

https://issues.dlang.org/show_bug.cgi?id=6019 Walter Bright changed: What|Removed |Added See Also||https://issues.dlang.org/sh

[Issue 6019] Phobos imports in autogenerated .di header files break implicit linking with DLLs

https://issues.dlang.org/show_bug.cgi?id=6019 Walter Bright changed: What|Removed |Added See Also||https://issues.dlang.org/sh

[Issue 6019] Phobos imports in autogenerated .di header files break implicit linking with DLLs

https://issues.dlang.org/show_bug.cgi?id=6019 Walter Bright changed: What|Removed |Added See Also||https://issues.dlang.org/sh

[Issue 6019] Phobos imports in autogenerated .di header files break implicit linking with DLLs

https://issues.dlang.org/show_bug.cgi?id=6019 Walter Bright changed: What|Removed |Added See Also||https://issues.dlang.org/sh

[Issue 6019] Phobos imports in autogenerated .di header files break implicit linking with DLLs

https://issues.dlang.org/show_bug.cgi?id=6019 Richard Cattermole changed: What|Removed |Added Keywords|bootcamp| CC|

[Issue 9285] dtoh utility - convert D files to C++ header files

https://issues.dlang.org/show_bug.cgi?id=9285 Seb changed: What|Removed |Added Status|NEW |RESOLVED CC|

Re: DPP: Linker issue with functions implemented in C header files

On Tuesday, 18 February 2020 at 09:20:08 UTC, Andre Pany wrote: Hi Petar, Hi Andre, I'm happy to help :) thank you very much for the explanation and the code sample. Filling the az_span anonymous member was the tricky part, I thought it would be not possible to do so, but you showed me the

Re: DPP: Linker issue with functions implemented in C header files

On Tuesday, 18 February 2020 at 08:32:47 UTC, Petar Kirov [ZombineDev] wrote: On Tuesday, 18 February 2020 at 05:41:38 UTC, Andre Pany wrote: Hi, I try to get wrap the "Azure SDK for C" using DPP and have following issue. Functions, which are actually implemented in C header files

Re: DPP: Linker issue with functions implemented in C header files

On Tuesday, 18 February 2020 at 05:41:38 UTC, Andre Pany wrote: Hi, I try to get wrap the "Azure SDK for C" using DPP and have following issue. Functions, which are actually implemented in C header files will cause linker errors: https://github.com/Azure/azure-sdk-for-c/blob/maste

DPP: Linker issue with functions implemented in C header files

Hi, I try to get wrap the "Azure SDK for C" using DPP and have following issue. Functions, which are actually implemented in C header files will cause linker errors: https://github.com/Azure/azure-sdk-for-c/blob/master/sdk/core/core/inc/az_span.h#L91 Example: AZ_NODISCARD AZ_INLI

Re: Building GDC with auto-generated header files

Am Tue, 30 Jul 2019 15:19:44 +1200 schrieb rikki cattermole: > On 30/07/2019 4:11 AM, Eduard Staniloiu wrote: >> Cheers, everybody >> >> I'm working on this as part of my GSoC project [0]. >> >> I'm working on building gdc with the auto-generated `frontend.h` [1], >> but I'm having some issues

Re: Building GDC with auto-generated header files

On 30/07/2019 4:11 AM, Eduard Staniloiu wrote: Cheers, everybody I'm working on this as part of my GSoC project [0]. I'm working on building gdc with the auto-generated `frontend.h` [1], but I'm having some issues There are functions in dmd that don't have an `extern (C)` or `extern (C++)`

Building GDC with auto-generated header files

Cheers, everybody I'm working on this as part of my GSoC project [0]. I'm working on building gdc with the auto-generated `frontend.h` [1], but I'm having some issues There are functions in dmd that don't have an `extern (C)` or `extern (C++)` but they are used by gdc (are exposed in `.h`

Re: Interfacing with C libs: weeding through C/C++ macros and such in header files

On Sunday, 13 January 2019 at 22:40:57 UTC, Alec Stewart wrote: Example without code; for some reason a macro is defined for the stdlib functions `malloc`, `realloc`, and `free`. Maybe it's just because I don't have any pro experience with C or C++, but that seems a bit excessive. Or I

Re: Interfacing with C libs: weeding through C/C++ macros and such in header files

On Sunday, 13 January 2019 at 23:23:50 UTC, Alex wrote: These three are members of the standard library in D. https://dlang.org/phobos/core_memory.html Ah, yea that's way easier. At first, I would suggest to try out some automatic converters, which are written by the community:

Re: Interfacing with C libs: weeding through C/C++ macros and such in header files

On Sunday, 13 January 2019 at 22:40:57 UTC, Alec Stewart wrote: Example without code; for some reason a macro is defined for the stdlib functions `malloc`, `realloc`, and `free`. Maybe it's just because I don't have any pro experience with C or C++, but that seems a bit excessive. Or I could

Interfacing with C libs: weeding through C/C++ macros and such in header files

Hello all! So while I have a decent grasp on D, I've been having trouble figuring out specific projects that I could do in D, so I thought I'd maybe find a little C or C++ library I could transfer over to D. I decided to make my life easier and look for something that's just a single header

[Issue 18589] New: Windows header files: bcrypt and ncrypt

https://issues.dlang.org/show_bug.cgi?id=18589 Issue ID: 18589 Summary: Windows header files: bcrypt and ncrypt Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: enhancement

[Issue 18363] New: we should autogenerate duplicate “.h” header files in dmd to keep them in sync

https://issues.dlang.org/show_bug.cgi?id=18363 Issue ID: 18363 Summary: we should autogenerate duplicate “.h” header files in dmd to keep them in sync Product: D Version: D2 Hardware: x86 OS: All

[Issue 6019] Phobos imports in autogenerated .di header files break implicit linking with DLLs

https://issues.dlang.org/show_bug.cgi?id=6019 Andrei Alexandrescu changed: What|Removed |Added Keywords||bootcamp

Re: A case for -H header files, avoid repeating expensive compile-time calculations

On 28/08/2016 6:34 AM, cy wrote: I made a module that looped for a while in compile time (since you can't sleep during compile time), to see if I could pre-compile the module, and thus save time compiling the main application. It didn't work at first, because any file that depended on the module

A case for -H header files, avoid repeating expensive compile-time calculations

I made a module that looped for a while in compile time (since you can't sleep during compile time), to see if I could pre-compile the module, and thus save time compiling the main application. It didn't work at first, because any file that depended on the module would import it, and importing

Re: noob in c macro preprocessor hell converting gsl library header files

On Wednesday, 6 January 2016 at 13:36:03 UTC, data pulverizer wrote: I have been converting C numeric libraries and depositing them here: https://github.com/dataPulverizer. So far I have glpk and nlopt converted on a like for like c function basics. I am now stuck on the gsl library, primarily

noob in c macro preprocessor hell converting gsl library header files

I have been converting C numeric libraries and depositing them here: https://github.com/dataPulverizer. So far I have glpk and nlopt converted on a like for like c function basics. I am now stuck on the gsl library, primarily because of the preprocessor c code which I am very new to. The

Re: noob in c macro preprocessor hell converting gsl library header files

On Wednesday, 6 January 2016 at 13:59:44 UTC, John Colvin wrote: #define INLINE_FUN extern inline // used in gsl_pow_int.h: INLINE_FUN double gsl_pow_2(const double x) { return x*x; } Could I just ignore the INLINE_FUN and use alias for function pointer declaration? For example ... alias

[Issue 3306] bad function/delegate literal generated into header files

https://issues.dlang.org/show_bug.cgi?id=3306 Andrei Alexandrescu and...@erdani.com changed: What|Removed |Added Version|2.032 |D2 --

Re: Header Files

Am Sun, 10 May 2015 10:37:13 -0400 schrieb bitwise bitwise@gmail.com: I'm not sure I understand what you're trying to say. Bit I'm trying to hijack your thread and communicate that .di files are important for D since they allow the compiler to stop recursively importing modules at

Re: Header Files

On Monday, 11 May 2015 at 12:46:59 UTC, Marco Leise wrote: Am Sun, 10 May 2015 10:37:13 -0400 schrieb bitwise bitwise@gmail.com: I'm not sure I understand what you're trying to say. Bit I'm trying to hijack your thread and communicate that .di files are important for D since they

Re: Header Files

Am Mon, 11 May 2015 12:50:48 + schrieb weaselcat weasel...@gmail.com: On Monday, 11 May 2015 at 12:46:59 UTC, Marco Leise wrote: Am Sun, 10 May 2015 10:37:13 -0400 schrieb bitwise bitwise@gmail.com: I'm not sure I understand what you're trying to say. Bit I'm trying

Re: Header Files

for it being this way? Wouldn't it be much more useful if directories were preserved? Bit I agree, D modules are hierarchical and sometimes share the same base name. Header files are very important to short circuit the transitive import chain. We've already seen it in Phobos. Many modules ends up

Re: Header Files

On Sunday, 10 May 2015 at 01:00:31 UTC, bitwise wrote: Is there really no way to preserve the directory structure when creating .di files? Bit Why hello, Bitwise! I believe the '-op' flag is what you're looking for! Bitwiser

Re: Header Files

On Sun, 10 May 2015 04:20:45 -0400, Marco Leise marco.le...@gmx.de wrote: I agree, D modules are hierarchical and sometimes share the same base name. Header files are very important to short circuit the transitive import chain. We've already seen it in Phobos. Many modules ends up pulling

Re: Header Files

On 05/10/2015 09:11 AM, bitwise wrote: On Sunday, 10 May 2015 at 01:00:31 UTC, bitwise wrote: Is there really no way to preserve the directory structure when creating .di files? Bit Why hello, Bitwise! I believe the '-op' flag is what you're looking for! Bitwiser Wow! Walter has

Re: Header Files

On Sat, 09 May 2015 21:09:33 -0400, Ali Çehreli acehr...@yahoo.com wrote: On 05/09/2015 07:01 AM, bitwise wrote: ./main.d ./pack/foo.d ./pack/sub/bar.d dmd main.d pack/foo.d pack/sub/bar.d -ofTest -H This dumps all the *.di files into the output directory ignoring the directory structure.

Re: Header Files

On 05/09/2015 07:01 AM, bitwise wrote: ./main.d ./pack/foo.d ./pack/sub/bar.d dmd main.d pack/foo.d pack/sub/bar.d -ofTest -H This dumps all the *.di files into the output directory ignoring the directory structure. Is there some rational for it being this way? Wouldn't it be much more useful

Re: Header Files

On 05/09/2015 06:18 PM, bitwise wrote: I'm not sure I understand what you mean, but my point is, that as is, this feature of DMD is broken. Arguably broken but compared to other tools it behaves in the same way. If people are successfully using dmd -H right now, they must not be using

Re: Header Files

On Sat, 09 May 2015 21:31:20 -0400, Ali Çehreli acehr...@yahoo.com wrote: On 05/09/2015 06:18 PM, bitwise wrote: I'm not sure I understand what you mean, but my point is, that as is, this feature of DMD is broken. Arguably broken but compared to other tools it behaves in the same way.

Re: Header Files

On Sat, 09 May 2015 10:01:25 -0400, bitwise bitwise@gmail.com wrote: ./main.d ./pack/foo.d ./pack/sub/bar.d dmd main.d pack/foo.d pack/sub/bar.d -ofTest -H This dumps all the *.di files into the output directory ignoring the directory structure. Is there some rational for it being

[Issue 9285] dtoh utility - convert D files to C++ header files

https://issues.dlang.org/show_bug.cgi?id=9285 Issue 9285 depends on issue 11620, which changed state. Issue 11620 Summary: dmd json output should output enum values https://issues.dlang.org/show_bug.cgi?id=11620 What|Removed |Added

[Issue 9285] dtoh utility - convert D files to C++ header files

https://issues.dlang.org/show_bug.cgi?id=9285 --- Comment #14 from Andrej Mitrovic andrej.mitrov...@gmail.com --- https://issues.dlang.org/show_bug.cgi?id=11620 is now fixed, are there any other fixes needed for this tool? --

Some issues (bugs?) with generated header files

\package.d source\wba\wbWrapper.d source\wba\webbrowser.d source\wba\webBrowserForm.d -IC:\D\dmd2\src\druntime\import -IC:\D\dmd2\src\phobos -IC:\D\lib\WindowsAPI -lib -odobj\Header -ofJ:\Workspace\Libraries\WebBrowserApplication\bin\Header\wba.lib -H 3 issues: 1) While using the header files

Re: Some issues (bugs?) with generated header files

\wba.lib -H 3 issues: 1) While using the header files in another project, the package.di file does not work as expected. I cannot use statement: import wba; main.d(3): Error: module wba is in file 'wba.d' which cannot be read It only works if I rename package.di to package.d 2) property

Re: Some issues (bugs?) with generated header files

On Saturday, 5 April 2014 at 10:00:13 UTC, Andre wrote: 2) property methods doesn't work with header files. For this coding: @property docHostUIHandler() { return this._docHostUIHandler; } This di coding was created: @property docHostUIHandler

Re: Some issues (bugs?) with generated header files

Am 05.04.2014 12:49, schrieb evilrat: i have little info about this, but let me clear something for you. - interface generation is outdated/broken - .di files should be avoided now, this is why import looking for .d only, but idk why. - to avoid @property issue you can try adding export

Re: Some issues (bugs?) with generated header files

On Saturday, 5 April 2014 at 10:55:19 UTC, evilrat wrote: // recommended, manual type @property HostUIHandlerType() { return this._docHostUIHandler; } oops. this of course should be like normal function.

[Issue 9285] dtoh utility - convert D files to C++ header files

https://d.puremagic.com/issues/show_bug.cgi?id=9285 --- Comment #13 from Adam D. Ruppe destructiona...@gmail.com 2014-02-10 20:55:50 PST --- I haven't linked this in here yet so here it is: https://github.com/D-Programming-Language/tools/pull/39 Should be good enough to start using, then we

Re: What is the common way of porting opaque types in C header files?

On Friday, 13 December 2013 at 01:20:41 UTC, Mike Parker wrote: On 12/13/2013 7:52 AM, Gary Willoughby wrote: I have a lot of opaque types in C headers i'm porting to D. What is the best way to handle these? Would you just use void pointers? In the below example Tcl_AsyncHandler_ is not

What is the common way of porting opaque types in C header files?

I have a lot of opaque types in C headers i'm porting to D. What is the best way to handle these? Would you just use void pointers? In the below example Tcl_AsyncHandler_ is not defined anywhere. C: typedef struct Tcl_AsyncHandler_ *Tcl_AsyncHandler; D: alias void* Tcl_AsyncHandler;

Re: What is the common way of porting opaque types in C header files?

On 12/13/2013 7:52 AM, Gary Willoughby wrote: I have a lot of opaque types in C headers i'm porting to D. What is the best way to handle these? Would you just use void pointers? In the below example Tcl_AsyncHandler_ is not defined anywhere. C: typedef struct Tcl_AsyncHandler_

[Issue 9285] dtoh utility - convert D files to C++ header files

https://d.puremagic.com/issues/show_bug.cgi?id=9285 Martin Nowak c...@dawg.eu changed: What|Removed |Added CC||c...@dawg.eu --- Comment

[Issue 9285] dtoh utility - convert D files to C++ header files

https://d.puremagic.com/issues/show_bug.cgi?id=9285 --- Comment #10 from Adam D. Ruppe destructiona...@gmail.com 2013-11-27 11:43:21 PST --- Are there any more substantial comments on the code I wrote in January? I just tried to use it again, and there's some small updates needed. dmd's json

[Issue 9285] dtoh utility - convert D files to C++ header files

https://d.puremagic.com/issues/show_bug.cgi?id=9285 --- Comment #11 from Adam D. Ruppe destructiona...@gmail.com 2013-11-27 19:51:37 PST --- I cleaned up and updated my old code so it works with new dmd again: http://arsdnet.net/dcode/dtoh.zip There's still some fixmes in there i can fix,

[Issue 6019] Phobos imports in autogenerated .di header files break implicit linking with DLLs

http://d.puremagic.com/issues/show_bug.cgi?id=6019 --- Comment #9 from Martin Nowak c...@dawg.eu 2013-10-02 04:42:10 PDT --- *** Issue 9220 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving

[Issue 6019] Phobos imports in autogenerated .di header files break implicit linking with DLLs

http://d.puremagic.com/issues/show_bug.cgi?id=6019 --- Comment #11 from Martin Nowak c...@dawg.eu 2013-10-02 08:51:30 PDT --- (In reply to comment #10) How about this? Using weak undefined symbols to link against the imported ModuleInfo would result in null pointers during runtime. That

Re: Proof of concept: automatically import C header files

On 2013-07-18 00:59, H. S. Teoh wrote: IOW either you don't do it at all, or you have to go all the way and implement a fully-functional C frontend? If so, libclang is starting to sound rather attractive... That's what I'm telling Hmm. We *could* pre-preprocess the code to do this

Re: Proof of concept: automatically import C header files

On 2013-07-18 00:36, Walter Bright wrote: You could, but then you are left with failing to recognize: #define FOO 3 and converting it to: enum FOO = 3; And things like: #if linux short a; #elif _WIN32 || _WIN64 int a; #endif Should preferably be converted to: version (linux)

Re: Proof of concept: automatically import C header files

On 2013-07-17 21:40, Walter Bright wrote: Yes, but the front end itself must be complete. Otherwise, it's not really practical when you're dealing with things like the preprocessor - because a non-compliant front end won't even know it has gone off the rails. There are other issues when

Re: Proof of concept: automatically import C header files

On Wednesday, 17 July 2013 at 15:34:54 UTC, Jacob Carlborg wrote: On 2013-07-17 13:24, Paulo Pinto wrote: Thus we are back to the compiler as library discussion. Yes, but for the C family of languages we already have a compiler as library, that is Clang. Agreed. I also confess that my

Re: Proof of concept: automatically import C header files

On Wednesday, 17 July 2013 at 05:12:00 UTC, Timothee Cour wrote: what's a non-full C front end? If it's not a real C front end it's gonna break with certain macros etc. Not good. Macro are processed before parsing? No need for a full C frontend to handle macros. I see no point in

Re: Proof of concept: automatically import C header files

Possibly instead of 'include' would be better use 'include_C' as opposed to C++ or any other language.

Re: Proof of concept: automatically import C header files

On Tue, Jul 16, 2013 at 11:01 PM, deadalnix deadal...@gmail.com wrote: On Wednesday, 17 July 2013 at 05:12:00 UTC, Timothee Cour wrote: what's a non-full C front end? If it's not a real C front end it's gonna break with certain macros etc. Not good. Macro are processed before parsing? No

Re: Proof of concept: automatically import C header files

On Tuesday, 16 July 2013 at 14:15:55 UTC, Jacob Carlborg wrote: Made a proof of concept to automatically parse, translate and import C header files in D using DStep. DMD is linked against DStep and does not start new process to make the translation. I added a new pragma, include, that handles

Re: Proof of concept: automatically import C header files

On 7/16/2013 10:04 PM, deadalnix wrote: On Wednesday, 17 July 2013 at 04:14:56 UTC, Walter Bright wrote: On 7/16/2013 8:49 PM, Timothee Cour wrote: So how about a library solution instead, which doesn't require compiler change: While semantically a great idea, technically I don't think CTFE

Re: Proof of concept: automatically import C header files

On 2013-07-17 08:29, angel wrote: Possibly instead of 'include' would be better use 'include_C' as opposed to C++ or any other language. Or there could be an optional argument indicating the language. pragma(include, foo.h, C); -- /Jacob Carlborg

Re: Proof of concept: automatically import C header files

On 2013-07-17 07:04, deadalnix wrote: This is the right path. We don't need the full front end, do we ? Oh, yes we do. You will always run into corner cases your tool cannot handle until you have a complete front end. I tried that first, before I used libclang. -- /Jacob Carlborg

Re: Proof of concept: automatically import C header files

On 2013-07-16 17:05, Dicebot wrote: While this a relatively common request, I don't think such stuff belongs to compiler. It creates extra mandatory dependencies while providing little advantage over doing this as part of a build system. I started to think a bit about this. One might need to

Re: Proof of concept: automatically import C header files

On 2013-07-17 10:14, Walter Bright wrote: Yeah, you do need the full front end. It's pretty amazing how the simplest of .h files seem determined to exercise every last, dark corner of the language. If the converter doesn't accept the full language, you're just going to get a dump truck

Re: Proof of concept: automatically import C header files

On Wednesday, 17 July 2013 at 09:27:53 UTC, Jacob Carlborg wrote: On 2013-07-17 10:14, Walter Bright wrote: Yeah, you do need the full front end. It's pretty amazing how the simplest of .h files seem determined to exercise every last, dark corner of the language. If the converter doesn't

Re: Proof of concept: automatically import C header files

On 2013-07-17 13:24, Paulo Pinto wrote: Thus we are back to the compiler as library discussion. Yes, but for the C family of languages we already have a compiler as library, that is Clang. -- /Jacob Carlborg

Re: Proof of concept: automatically import C header files

On Wednesday, 17 July 2013 at 07:17:07 UTC, Timothee Cour wrote: you'd still need to parse C files recursively (textual inclusion...), handle different C function calling conventions, different C standards, you'd need a way to forward to dmd different C compiler options (include paths to

Re: Proof of concept: automatically import C header files

On Wednesday, 17 July 2013 at 09:27:53 UTC, Jacob Carlborg wrote: On 2013-07-17 10:14, Walter Bright wrote: Yeah, you do need the full front end. It's pretty amazing how the simplest of .h files seem determined to exercise every last, dark corner of the language. If the converter doesn't

Re: Proof of concept: automatically import C header files

On 7/17/2013 2:27 AM, Jacob Carlborg wrote: On 2013-07-17 10:14, Walter Bright wrote: Yeah, you do need the full front end. It's pretty amazing how the simplest of .h files seem determined to exercise every last, dark corner of the language. If the converter doesn't accept the full language,

Re: Proof of concept: automatically import C header files

On 7/17/2013 9:48 AM, deadalnix wrote: My understanding is that we only want to convert declaration to D. Can you give me an example of such corner case that would require the full frontend ? One example:

Re: Proof of concept: automatically import C header files

On Wed, Jul 17, 2013 at 12:46:54PM -0700, Walter Bright wrote: On 7/17/2013 9:48 AM, deadalnix wrote: My understanding is that we only want to convert declaration to D. Can you give me an example of such corner case that would require the full frontend ? One example:

Re: Proof of concept: automatically import C header files

On 7/17/2013 3:20 PM, H. S. Teoh wrote: Though about trigraphs... I've to admit I've never actually seen *real* C code that uses trigraphs, but yeah, needing to account for them can significantly complicate your code. Building a correct C front end is a known technology, doing a half-baked job

Re: Proof of concept: automatically import C header files

On Wed, Jul 17, 2013 at 03:36:15PM -0700, Walter Bright wrote: On 7/17/2013 3:20 PM, H. S. Teoh wrote: Though about trigraphs... I've to admit I've never actually seen *real* C code that uses trigraphs, but yeah, needing to account for them can significantly complicate your code. Building a

Re: Proof of concept: automatically import C header files

On Wednesday, 17 July 2013 at 19:46:54 UTC, Walter Bright wrote: On 7/17/2013 9:48 AM, deadalnix wrote: My understanding is that we only want to convert declaration to D. Can you give me an example of such corner case that would require the full frontend ? One example:

Re: Proof of concept: automatically import C header files

On 7/17/2013 5:31 PM, deadalnix wrote: On Wednesday, 17 July 2013 at 19:46:54 UTC, Walter Bright wrote: On 7/17/2013 9:48 AM, deadalnix wrote: My understanding is that we only want to convert declaration to D. Can you give me an example of such corner case that would require the full frontend

Proof of concept: automatically import C header files

Made a proof of concept to automatically parse, translate and import C header files in D using DStep. DMD is linked against DStep and does not start new process to make the translation. I added a new pragma, include, that handles everything. Use like this: // foo.h void foo (); // main.d

Re: Proof of concept: automatically import C header files

On Tuesday, 16 July 2013 at 14:15:55 UTC, Jacob Carlborg wrote: Made a proof of concept to automatically parse, translate and import C header files in D using DStep. DMD is linked against DStep and does not start new process to make the translation. awesome! :-)

Re: Proof of concept: automatically import C header files

On Tuesday, 16 July 2013 at 14:15:55 UTC, Jacob Carlborg wrote: Made a proof of concept to automatically parse, translate and import C header files in D using DStep. DMD is linked against DStep and does not start new process to make the translation. While this a relatively common request, I

Re: Proof of concept: automatically import C header files

On Tue, Jul 16, 2013 at 8:05 AM, Dicebot pub...@dicebot.lv wrote: On Tuesday, 16 July 2013 at 14:15:55 UTC, Jacob Carlborg wrote: Made a proof of concept to automatically parse, translate and import C header files in D using DStep. DMD is linked against DStep and does not start new process

  1   2   3   >