On Tuesday, 3 December 2013 at 09:28:11 UTC, Iain Buclaw wrote:
On 3 December 2013 02:43, Mike <[email protected]> wrote:
Personally I feel that people porting to specific
architectures should
maintain their differences in separate files under a /ports
directory
structure - lets say core.stdc.stdio as a cod example. The
version for
bionic would be under /ports/bionic/core/stdc/stdio.d, and
that is the
module that gets compiled into the library when building for
bionic.
When installing, the build process generates a header file of
the
bionic version of core.stdc.stdio and puts the file in the
correct
/include/core/stdc/stdio.di location.
Though it is fine to say using version {} else version {}
else static
assert(false); when dealing with a small set of
architectures. I feel
strongly this is not practical when considering there are 23+
architectures and 12+ platforms that could be in mixed
combination.
The result would either be lots of code duplications
everywhere, or
just a wiry long block of spaghetti code. Every port in one
file
would (eventually) make it difficult for maintainers IMO.
I agree. Submitted an enhancement here:
https://d.puremagic.com/issues/show_bug.cgi?id=11666
Thanks.
My name is Iain.
Iain (sorry for the misspelling),
I'm wondering if you could please elaborate on the following
statement:
"When installing, the build process generates a header file of
the bionic version of core.stdc.stdio and puts the file in the
correct /include/core/stdc/stdio.di location."
Being new to D and the D Runtime build process, while I
understand the general principle, I'm not seeing exactly how this
can be implemented.
* How are header files generated in the build process?
* Once all the necessary files are generated, what need to be
done to tell the compiler to "use this one"?
Also, D has "header files"? Tell me it isn't so. Did you mean a
.di file? Are these called "header files"?
