Re: More automated interfacing of D with C codebases
On 2012-10-23 21:43, Brad Lanam wrote: Oh, maybe were you thinking that bash is the bourne shell? It's the bourne-again shell, a rewrite of the bourne shell. Solaris sh is probably the closest to the original bourne shell. I thought I said bash somewhere, but perhaps you didn't. My tool runs with any bourne shell compatible shell. It works with bash2, bash3, bash4, ksh, ksh88, ksh93, Solaris sh, Tru64 sh, ash, dash, mksh, pdksh. HP-UX sh. I see. You put directives in the interface file (to use the SWIG term) to test which capabilities the system has. It creates an output file (.sh, .c, .d). Depending on those capabilities, the code can use #if or static if statements to provide code that works for the system you are building on. In the case of the C/D language interface, the directives will extract typedefs, structures, C function declarations, macros, #defines. Ok, I see. -- /Jacob Carlborg
Re: More automated interfacing of D with C codebases
On 2012-10-22 21:48, Brad Lanam wrote: Nothing wrong with that. I had different goals -- portability and legacy systems. My tool is all bourne shell and awk. There aren't many systems it does not work on (e.g. ULTRIX shell runs out of memory). How can you mention bourne shell and portability in the same sentence? I doesn't work on Windows (yes I know about cygwin and mingw). Clang does work on Windows, I just haven't been able to compile DStep for Windows yet due to optlink not cooperating. Sure, if you're satisfied with Posix then I guess that's fine. But it's not really easy to build cross-platform code with shell script. I should also state my tool was written as a build configuration tool (like autoconf/iffe/dist), not a conversion tool. SWIG is better supported, faster and supports more languages. If you need to write code that runs on multiple systems and works with low level system calls (rpc, et.al.), my tool might be a better choice. Why would that make a difference. This sort of thing (from the D compiler): #if __sun #includealloca.h #endif Is nuts. I thought everyone had gotten away from that sort of thing (it died out in the mid-eighties!), but I still see it in code everywhere. The system should be tested for its capabilities and what it has available, not whether it is a sun machine. DMD (DMC) is from the eighties. It sill uses the .c for its C++ files. -- /Jacob Carlborg
Re: More automated interfacing of D with C codebases
On 2012-10-23 07:09, timotheecour wrote:
If you try to automate processing of the pre-processed headers,
all of the included system headers will be processed and too much that
isn't needed will be output.
Swig has lots of customization to control what gets translated. For
example, we recursively translate the contents of header files or just
the contents minus without looking into the include statements (the
default):
b.h:
void funb();
a.h:
#include b.h
void funa();
%{
%include a.h
%}
%include a.h
= the default is NOT to inlude funb(), which is inside an include
statement.
I'm only translating what's in the main header file, i.e. the one you
gave on the command line. I have access to source information of where a
given symbol is declared, if it doesn't match the main header file it's
not translated.
If SWIG has a full blown C++ parser, then why is it choking on some
code?
One example is when there's no D equivalent, eg multiple inheritance.
But there are more:
actually in the example above, if I understand correctly, the stuff
inside the %{ %} uses the full blown C++ parser, whereas the stuff after
has some swig specificities and sometimes can't handle certain rare
constructs if one uses the lazy approach that I've taken of translating
the whole header file (%include a.h):
some stuff it choked on:
A) typedef Matx_Tp, MIN(m, n), 1 diag_type;
B) void addParam( int (Algorithm::*getter)()=0)
If there's something I can't translate to D I just skip it. I could
output a warning, some kind of static assert in the code or whatever.
The tool can still handle the file.
--
/Jacob Carlborg
Re: More automated interfacing of D with C codebases
On Tuesday, 23 October 2012 at 06:35:06 UTC, Jacob Carlborg wrote:
On 2012-10-22 21:48, Brad Lanam wrote:
How can you mention bourne shell and portability in the same
sentence? I doesn't work on Windows (yes I know about cygwin
and mingw). Clang does work on Windows, I just haven't been
able to compile DStep for Windows yet due to optlink not
cooperating.
Sure, if you're satisfied with Posix then I guess that's fine.
But it's not really easy to build cross-platform code with
shell script.
I'm sorry, I don't see how that follows. My scripts work on All
variants of Linux (2.4, 2.6), Solaris (2.6 - 11), AIX, Tru64,
HP-UX, All *BSD, Mac OSX, Haiku, QNX, SCO, Syllable, UnixWare,
Windows Cygwin. My 'di' program builds on all of the above with
a simple 'make' as it uses my build tool. And I don't need to
install any special tools. These are just the systems I have
access to.
How is that not cross-platform? How is that not portable? How
is that not easy?
If I had a D compiler on all those platforms, the D version of
the 'di' program would build everywhere with just a 'make'.
If you need to write code that runs on multiple systems and
works with
low level system calls (rpc, et.al.), my tool might be a
better choice.
Why would that make a difference.
Not all systems are alike.
static if (_c_args_setmntent == 1)
{
f = setmntent (toStringz(DI_MOUNT_FILE));
} else static if (_c_args_setmntent == 2) {
f = setmntent (toStringz(DI_MOUNT_FILE), toStringz(r));
}
If I understand your tool correctly, you might convert the
mount.h or mntent.h file [but how does your program decide which
one and even if they exist?]. But then how are you going to
change your code to handle the above? You've got a *lot* of work
to do if you want a cross platform tool.
I recommend SWIG+CMAKE. Or my 'mkconfig' tool.
Re: More automated interfacing of D with C codebases
On 2012-10-23 19:42, Brad Lanam wrote:
I'm sorry, I don't see how that follows. My scripts work on All
variants of Linux (2.4, 2.6), Solaris (2.6 - 11), AIX, Tru64, HP-UX, All
*BSD, Mac OSX, Haiku, QNX, SCO, Syllable, UnixWare, Windows Cygwin. My
'di' program builds on all of the above with a simple 'make' as it uses
my build tool. And I don't need to install any special tools. These
are just the systems I have access to.
All of these don't use the same shell. Requiring to install bash would
mean you do need to install special tools. Not really special but
additional tools. But I would count Cygwin as a special tool for Windows.
How is that not cross-platform? How is that not portable? How is that
not easy?
If I had a D compiler on all those platforms, the D version of the 'di'
program would build everywhere with just a 'make'.
If you need to write code that runs on multiple systems and works with
low level system calls (rpc, et.al.), my tool might be a better choice.
Why would that make a difference.
Not all systems are alike.
static if (_c_args_setmntent == 1)
{
f = setmntent (toStringz(DI_MOUNT_FILE));
} else static if (_c_args_setmntent == 2) {
f = setmntent (toStringz(DI_MOUNT_FILE), toStringz(r));
}
If I understand your tool correctly, you might convert the mount.h or
mntent.h file [but how does your program decide which one and even if
they exist?]. But then how are you going to change your code to handle
the above? You've got a *lot* of work to do if you want a cross
platform tool.
I recommend SWIG+CMAKE. Or my 'mkconfig' tool.
Well then, how does your tool work?
--
/Jacob Carlborg
Re: More automated interfacing of D with C codebases
On Tuesday, 23 October 2012 at 19:10:29 UTC, Jacob Carlborg wrote:
On 2012-10-23 19:42, Brad Lanam wrote:
All of these don't use the same shell. Requiring to install
bash would mean you do need to install special tools. Not
really special but additional tools. But I would count Cygwin
as a special tool for Windows.
Oh, maybe were you thinking that bash is the bourne shell? It's
the
bourne-again shell, a rewrite of the bourne shell. Solaris sh is
probably the closest to the original bourne shell.
My tool runs with any bourne shell compatible shell. It works
with bash2, bash3, bash4, ksh, ksh88, ksh93, Solaris sh, Tru64 sh,
ash, dash, mksh, pdksh. HP-UX sh.
If you need to write code that runs on multiple systems and
works with
low level system calls (rpc, et.al.), my tool might be a
better choice.
Why would that make a difference.
Not all systems are alike.
static if (_c_args_setmntent == 1)
{
f = setmntent (toStringz(DI_MOUNT_FILE));
} else static if (_c_args_setmntent == 2) {
f = setmntent (toStringz(DI_MOUNT_FILE),
toStringz(r));
}
If I understand your tool correctly, you might convert the
mount.h or
mntent.h file [but how does your program decide which one and
even if
they exist?]. But then how are you going to change your code
to handle
the above? You've got a *lot* of work to do if you want a
cross
platform tool.
I recommend SWIG+CMAKE. Or my 'mkconfig' tool.
Well then, how does your tool work?
You put directives in the interface file (to use the SWIG term)
to test which capabilities the system has. It creates an output
file (.sh, .c, .d). Depending on those capabilities, the code can
use #if or static if statements to provide code that works for
the system you are building on.
In the case of the C/D language interface, the directives will
extract typedefs, structures, C function declarations, macros,
#defines.
Re: More automated interfacing of D with C codebases
On 2012-10-21 21:45, timotheecour wrote: Manually porting of C/C++ libraries shouldn't be the way to go (a major problem being when said library gets updated, human errors, porting to different architectures etc). SWIG requires some kind of interface files, which I assume one must have to manually write. Then what's the difference? I've had good experience using SWIG to automate the job for me, and used it successfully to port the following libraries to D: * ncurses * opencv * sfml to name a few. I believe this is the way forward, as opposed to maintaining (necessary stale) ports such as Deimos. Swig isn't perfect however, and sometimes will bail out on constructs such as: C++ classes with multiple inheritance, or a few obscure C or C++ constructs. Even in that case, I find it much easier to tweak the swig interface file to get desired output rather than undertake the huge manual conversion task. For sfml, the interface file is just about 40 lines for example. Improving such kind of automated tools is where we should be concentrating efforts, not on maintaining deimos. One such improvement I made was to allow conversion of C++ templates to D templates (works in large majority of cases), which makes the library much easier to use than using name mangling schemes. More improvements would be welcome (eg support for static library generation as opposed to dynamic load libraries), reducing the need for tweaking swig interface files etc. I don't think SWIG is the right approach because: * You have to create these interface files * It seem to not handle all code * No support for Objective-C BTW, how does SWIG handle macros and documentation? -- /Jacob Carlborg
Re: More automated interfacing of D with C codebases
SWIG requires some kind of interface files, which I assume one
must have to manually write. Then what's the difference?
These can be as small as:
sfml.i:
%{
#include SFML/Audio.hpp
%}
%include SFML/Config.hpp
%include SFML/Audio/Export.hpp
In practice, some additional tweaks may be needed to support
certain constructs like multiple inheritance, etc, but nothing
daunting (~ 50 lines of code for my sfml interface file)
I don't think SWIG is the right approach because:
* You have to create these interface files
=
see above. Interface files can be very small.
* It seem to not handle all code
I was still able to port large libraries like sfml and opencv,
using tweaks to the interface files and enhancing swig to support
C++template to D template conversion. There's a small number of
cases where swig currently chokes, some of which could be easily
fixed if there's enough demand.
* No support for Objective-C
=
http://www.swig.org/Doc1.1/HTML/SWIG.html#n7
One of SWIG's most recent additions is support for Objective-C
parsing. This is currently an experimental feature that may be
improved in future releases.
BTW, how does SWIG handle macros and documentation?
You'd have to write a C/C++ function that does what the macro
does in the interface file, which would in turn be converted to a
D function.
For exporting C documentation to D, I've asked on stackoverflow:
http://stackoverflow.com/questions/12413957/export-comments-in-swig-wrapper
I'm not sure it's supported ATM, but that's definitely something
possible since swig has a full blown C++ parser.
Re: More automated interfacing of D with C codebases
correction regarding macros:
myheader.h:
#define MEX_INFORMATION_VERSION 1
interface file myheader.i:
%{
%include myheader.h
%}
%include myheader.h
generated d file will contain:
int MEX_INFORMATION_VERSION() @property {
auto ret = swig.mex_im.swig_mex_MEX_INFORMATION_VERSION_get();
return ret;
}
which allows one to use the macro from D. Certainly not the best
way (an enum would be preferable) but it works. Again, swig could
be improved. Also if static libraries could be generated, the
overhead above wouldn't be such a big deal with link time
optimization.
For functional macros, I'm not sure, but once can write a C
function that calls the macro, and then swig will convert to D
function. Ideally, swig would directly convert it to a templated
function.
I think maintaining a repository of interface files would be a
better idea than maintaining manually converted C files. The
former would be much smaller easier to maintain, and for 99%
cases stay in sync with library updates. The latter would end up
as a graveyard of never up to date partially-portable C ports
that no-one will want to maintain.
Re: More automated interfacing of D with C codebases
On Monday, 22 October 2012 at 06:28:12 UTC, Jacob Carlborg wrote: On 2012-10-21 21:45, timotheecour wrote: Manually porting of C/C++ libraries shouldn't be the way to go (a major problem being when said library gets updated, human errors, porting to different architectures etc). SWIG requires some kind of interface files, which I assume one must have to manually write. Then what's the difference? Huge difference. It's not necessary to figure out corresponding type sizes on every system. I only need to figure out what needs to be in there. And once all the work of creating the interface file is done, the work of porting to another architecture or operating system or compiler is much reduced. It's not necessary to figure out which api calls are macros on arch XYZ or are simply not there: cdcl Tcl_IncrRefCount clib Tcl_IncrRefCount # if Tcl_IncrRefCount is not defined as a library call, search for the macro. if lib_Tcl_IncrRefCount ! _clib_Tcl_IncrRefCount cmacro Tcl_IncrRefCount tcl.h void 'Tcl_Obj *' endif My example Tck/Tk conversion doesn't handle 8.6, but the effort to add it will be very minimal. All of the hard work of discovering the needed typedefs has been done. [...] I don't think SWIG is the right approach because: * You have to create these interface files * It seem to not handle all code I don't know SWIG, but the idea is the same for my tool. If you try to automate processing of the pre-processed headers, all of the included system headers will be processed and too much that isn't needed will be output. The included system definitions will conflict with D definitions. I'm not sure that handling *all* code is necessary. How often do you see this sort of thing in C code? _XPrivate .private9, .private10; Rather than spend effort on handling *every* possible obscure C/C++/ObjC construct, it's easier to simply handle those in the interface file. Other constructs that are more common can be added to SWIG or to my tool. They're both open source. -- Brad
Re: More automated interfacing of D with C codebases
On 2012-10-22 19:27, timotheecour wrote:
SWIG requires some kind of interface files, which I assume one must
have to manually write. Then what's the difference?
These can be as small as:
sfml.i:
%{
#include SFML/Audio.hpp
%}
%include SFML/Config.hpp
%include SFML/Audio/Export.hpp
In practice, some additional tweaks may be needed to support certain
constructs like multiple inheritance, etc, but nothing daunting (~ 50
lines of code for my sfml interface file)
I don't think SWIG is the right approach because:
* You have to create these interface files
=
see above. Interface files can be very small.
* It seem to not handle all code
I was still able to port large libraries like sfml and opencv, using
tweaks to the interface files and enhancing swig to support C++template
to D template conversion. There's a small number of cases where swig
currently chokes, some of which could be easily fixed if there's enough
demand.
* No support for Objective-C
=
http://www.swig.org/Doc1.1/HTML/SWIG.html#n7
One of SWIG's most recent additions is support for Objective-C parsing.
This is currently an experimental feature that may be improved in future
releases.
BTW, how does SWIG handle macros and documentation?
You'd have to write a C/C++ function that does what the macro does in
the interface file, which would in turn be converted to a D function.
For exporting C documentation to D, I've asked on stackoverflow:
http://stackoverflow.com/questions/12413957/export-comments-in-swig-wrapper
I'm not sure it's supported ATM, but that's definitely something
possible since swig has a full blown C++ parser.
Ok, I see.
If SWIG has a full blown C++ parser, then why is it choking on some
code? Or does it need a semantic analyzer as well.
--
/Jacob Carlborg
Re: More automated interfacing of D with C codebases
On 2012-10-22 20:38, Brad Lanam wrote: Huge difference. It's not necessary to figure out corresponding type sizes on every system. I only need to figure out what needs to be in there. And once all the work of creating the interface file is done, the work of porting to another architecture or operating system or compiler is much reduced. It's not necessary to figure out which api calls are macros on arch XYZ or are simply not there: cdcl Tcl_IncrRefCount clib Tcl_IncrRefCount # if Tcl_IncrRefCount is not defined as a library call, search for the macro. if lib_Tcl_IncrRefCount ! _clib_Tcl_IncrRefCount cmacro Tcl_IncrRefCount tcl.h void 'Tcl_Obj *' endif My example Tck/Tk conversion doesn't handle 8.6, but the effort to add it will be very minimal. All of the hard work of discovering the needed typedefs has been done. [...] I don't think SWIG is the right approach because: * You have to create these interface files * It seem to not handle all code I don't know SWIG, but the idea is the same for my tool. If you try to automate processing of the pre-processed headers, all of the included system headers will be processed and too much that isn't needed will be output. The included system definitions will conflict with D definitions. I'm not sure that handling *all* code is necessary. How often do you see this sort of thing in C code? _XPrivate .private9, .private10; Rather than spend effort on handling *every* possible obscure C/C++/ObjC construct, it's easier to simply handle those in the interface file. Other constructs that are more common can be added to SWIG or to my tool. They're both open source. I prefer the approach I took when I created DStep, it uses libclang. The tool can parse all C(++) and Objective-C(++) code that clang can. Although it currently won't generate code for everything, at least it doesn't choke any code. I also get all bug fixes and new languages features for free when they're added to clang. No need to create interface files. -- /Jacob Carlborg
Re: More automated interfacing of D with C codebases
On 2012-10-22 19:27, timotheecour wrote: http://www.swig.org/Doc1.1/HTML/SWIG.html#n7 One of SWIG's most recent additions is support for Objective-C parsing. This is currently an experimental feature that may be improved in future releases. Will this generate C code or can it be made to generate something like this: http://michelf.ca/projects/d-objc/syntax/ -- /Jacob Carlborg
Re: More automated interfacing of D with C codebases
On Monday, 22 October 2012 at 19:12:46 UTC, Jacob Carlborg wrote: On 2012-10-22 20:38, Brad Lanam wrote: I prefer the approach I took when I created DStep, it uses libclang. The tool can parse all C(++) and Objective-C(++) code that clang can. Although it currently won't generate code for everything, at least it doesn't choke any code. I also get all bug fixes and new languages features for free when they're added to clang. No need to create interface files. Nothing wrong with that. I had different goals -- portability and legacy systems. My tool is all bourne shell and awk. There aren't many systems it does not work on (e.g. ULTRIX shell runs out of memory). I should also state my tool was written as a build configuration tool (like autoconf/iffe/dist), not a conversion tool. SWIG is better supported, faster and supports more languages. If you need to write code that runs on multiple systems and works with low level system calls (rpc, et.al.), my tool might be a better choice. This sort of thing (from the D compiler): #if __sun #includealloca.h #endif Is nuts. I thought everyone had gotten away from that sort of thing (it died out in the mid-eighties!), but I still see it in code everywhere. The system should be tested for its capabilities and what it has available, not whether it is a sun machine. -- Brad
Re: More automated interfacing of D with C codebases
On Monday, 22 October 2012 at 19:12:46 UTC, Jacob Carlborg wrote: On 2012-10-22 20:38, Brad Lanam wrote: I prefer the approach I took when I created DStep, it uses libclang. The tool can parse all C(++) and Objective-C(++) code that clang can. Although it currently won't generate code for everything, at least it doesn't choke any code. I also get all bug fixes and new languages features for free when they're added to clang. No need to create interface files. Nothing wrong with that. I had different goals -- portability and legacy systems. My tool is all bourne shell and awk. There aren't many systems it does not work on (e.g. ULTRIX shell runs out of memory). I should also state my tool was written as a build configuration tool (like autoconf/iffe/dist), not a conversion tool. SWIG is better supported, faster and supports more languages. If you need to write code that runs on multiple systems and works with low level system calls (rpc, et.al.), my tool might be a better choice. This sort of thing (from the D compiler): #if __sun #includealloca.h #endif Is nuts. I thought everyone had gotten away from that sort of thing (it died out in the mid-eighties!), but I still see it in code everywhere. The system should be tested for its capabilities and what it has available, not whether it is a sun machine. -- Brad
Re: More automated interfacing of D with C codebases
I don't think this is exactly what you want either, but it's certainly a lot easier than a manual process: http://gentoo.com/di/mkconfig.html (On Freecode) https://freecode.com/projects/mkconfig I just now released a new version. Freecode will be updated within 24 hours. Check the examples/dtcltk/ directory. There's also a simpler example within the D/ subdirectory in: http://gentoo.com/di/ Macros have to have their signature specified. e.g.: cmacro Tcl_InitMemory tcl.h void 'Tcl_Interp *' cmacro ScreenOfDisplay X11/Xlib.h 'Screen *' 'Display' int -- Brad
Re: More automated interfacing of D with C codebases
Manually porting of C/C++ libraries shouldn't be the way to go (a major problem being when said library gets updated, human errors, porting to different architectures etc). I've had good experience using SWIG to automate the job for me, and used it successfully to port the following libraries to D: * ncurses * opencv * sfml to name a few. I believe this is the way forward, as opposed to maintaining (necessary stale) ports such as Deimos. Swig isn't perfect however, and sometimes will bail out on constructs such as: C++ classes with multiple inheritance, or a few obscure C or C++ constructs. Even in that case, I find it much easier to tweak the swig interface file to get desired output rather than undertake the huge manual conversion task. For sfml, the interface file is just about 40 lines for example. Improving such kind of automated tools is where we should be concentrating efforts, not on maintaining deimos. One such improvement I made was to allow conversion of C++ templates to D templates (works in large majority of cases), which makes the library much easier to use than using name mangling schemes. More improvements would be welcome (eg support for static library generation as opposed to dynamic load libraries), reducing the need for tweaking swig interface files etc.
Re: More automated interfacing of D with C codebases
On Sunday, 21 October 2012 at 19:45:53 UTC, timotheecour wrote: I've had good experience using SWIG to automate the job for me, and used it successfully to port the following libraries to D: Yes. SWIG should be a lot faster than my tool. Also I don't have any units to handle C++ code. Completely agree. It has to be automated. Swig isn't perfect however, and sometimes will bail out on constructs such as: C++ classes with multiple inheritance, or a few obscure C or C++ constructs. Even in that case, I find it much easier to tweak If I recall, I ran into some obscure C constructs in the Tcl/Tk/X headers that I have never seen before. I believe I had to various aliases to my interface file to handle those. Also use of D reserved words had to be handled: substitute new new_ substitute class class_ substitute 'function;' 'function_;' And some things just plain won't work in D: # not valid D code. substitute '_XPrivate .private9, .private10;' \ '_XPrivate * private9, private10;'
Re: More automated interfacing of D with C codebases
On 2012-10-15 13:51, CapitalLetterC wrote: This will be my first posting here, but I've been obsessed with D since before there was a D2 standard. Despite that rather long period of obsession, it's only just now that I've started seriously using D as I attempt to code-up some POC projects to demonstrate that the language is mature enough for serious development, or at least the kind of development we're doing, anyway. So, that out of the way, I suppose I should apologize in advance for what must amount to a pretty dumb question, since I truly couldn't have been the first to think of this: with regard to interfacing D with C libraries, why would we require a project like Deimos which ensures that each codebase is ported, almost entirely, by hand? Theoretically, shouldn't there be some kind of autotools-like method to establish something like, config.d.in which is then used via abstractions to properly configure the rest of the D wrapper? Obviously, D doesn't have a preprocessor, but couldn't one synthesize that with a series of judicious version() blocks? Then, whenever someone goes to build the application on their system, you'd have something to a series of autoconf-like tests to fill in the proper sections of of config.d.in and get out a config.d suitable for their system. I'm really sorry if there's some stupidly obvious reason this couldn't work and I'm just not seeing it, or if this is some n00b question you get all the time. The header files need to be ported so D can find the declarations of the functions and types. There are a couple of tools that can do most of the work, but not completely. Macros are specially hard to port automatically. https://github.com/jacob-carlborg/dstep -- /Jacob Carlborg
Re: More automated interfacing of D with C codebases
On Monday, 15 October 2012 at 12:54:51 UTC, Jacob Carlborg wrote: On 2012-10-15 13:51, CapitalLetterC wrote: This will be my first posting here, but I've been obsessed with D since before there was a D2 standard. Despite that rather long period of obsession, it's only just now that I've started seriously using D as I attempt to code-up some POC projects to demonstrate that the language is mature enough for serious development, or at least the kind of development we're doing, anyway. So, that out of the way, I suppose I should apologize in advance for what must amount to a pretty dumb question, since I truly couldn't have been the first to think of this: with regard to interfacing D with C libraries, why would we require a project like Deimos which ensures that each codebase is ported, almost entirely, by hand? Theoretically, shouldn't there be some kind of autotools-like method to establish something like, config.d.in which is then used via abstractions to properly configure the rest of the D wrapper? Obviously, D doesn't have a preprocessor, but couldn't one synthesize that with a series of judicious version() blocks? Then, whenever someone goes to build the application on their system, you'd have something to a series of autoconf-like tests to fill in the proper sections of of config.d.in and get out a config.d suitable for their system. I'm really sorry if there's some stupidly obvious reason this couldn't work and I'm just not seeing it, or if this is some n00b question you get all the time. The header files need to be ported so D can find the declarations of the functions and types. There are a couple of tools that can do most of the work, but not completely. Macros are specially hard to port automatically. https://github.com/jacob-carlborg/dstep Actually, I understand perfectly well why the headers need to be ported to D code, what I was more wondering is if anybody knew of or had ever tried to use some kind of build system to automate the process to the greatest extent possible. So, for example, as a result of the configuration process certain features may be implicitly or explicitly enabled/disabled, without probing the individual user's configuration, you wouldn't know that, so how does one maximize portability, in that case? If you simply go to support the maximal set of features, you may wind up with a bunch of codepaths that go nowhere, likewise, if you choose only to support the minimal set of functionality, you may not wind up with code that's not useful to anyone, yourself included. Granted, I hadn't thought of the difficulty in porting things like macros, but I'd imagine that, in the absolute worst case, you could synthesize their behavior with templates. But there are all sorts of issues in that same vein, like how certain structs get put together, what types are aliased with what, etc. That's why I was wondering if you could handle this analogously to how C does, with a config file that gets setup by a kind of configuration system.
Re: More automated interfacing of D with C codebases
On 2012-10-15 19:20, CapitalLetterC wrote: But there are all sorts of issues in that same vein, like how certain structs get put together, what types are aliased with what, etc. That's why I was wondering if you could handle this analogously to how C does, with a config file that gets setup by a kind of configuration system. I think that would be possible but I haven't seen anyone program in D like that. -- /Jacob Carlborg
