[Issue 11666] Separate each platform's port to its own folder/file: aka "if version{} else version {}" getting out of control

[d-bugmail at puremagic.com]

https://d.puremagic.com/issues/show_bug.cgi?id=11666



--- Comment #5 from Iain Buclaw <ibuclaw at ubuntu.com> 2013-12-05 10:08:43 PST ---
(In reply to comment #4)
> (In reply to comment #0)
> > ** begin quote **
> > 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.
> 
> That sounds almost like a feasible approach. Can you go into more detail
> though.
> Would we create a complete copy of druntime under the ports tree or just for
> the files'that differ.
> What about the combinatorical explosion of libcs x archs, i.e.
> /ports/bionic_arm, /ports/bionic_x86 and /ports/glibc_ppc? Porting the bits
> folders for glibc would be the straightforward solution IMO, don't know about
> other C libs.
> How does this integrate with our core.sys.posix and core.sys.linux layers?

I'll have to sit and brood on this a little longer, but lets start with the
following definition I made up just now and destroy it as seen fit.

1) For each platform, we'll assume the default standard library. Alternative
libc implementation would require their own /port directory implementing the
entire druntime core.stdc.* - or at least the bits that they implement.

I'm not sure how bionic would fit into the current set-up because of the whole
conflict between Android/linux.  Arguably the bionic libc would come under as
an alternative libc implementation, and so we must throw it under /port.


2) Each platform gets it's own core.sys.xxx package.  So eg: we'll have
core.sys.android, core.sys.plan9, etc...


3) The platform versioning shall remain in place, leaving only architectural
differences to be thrown under /port

Lets take a recent example: struct fenv_t:

Implementation:

core/stdc/fenv.d:
---
  version (linux)
  {
    public import core.sys.linux.fenv_t;
  }

ports/x86/core/sys/linux/fenv_t.d
---
  module core.sys.linux.fenv_t;

  version (X86) {
    struct fenv_t { ... }
  }
  else
    static assert (false, "Some build-related error");


ports/x86_64/core/sys/linux/fenv_t.d
---
  module core.sys.linux.fenv_t;

  version (X86_64) {
    struct fenv_t { ... }
  }
  else
    static assert (false, "Some build-related error");


ports/generic/core/sys/linux/fenv_t.d
---
  module core.sys.linux.fenv_t;

  static assert (false, "fenv_t uimplementated for this architecture");



During the build process of druntime, all relevant sources for the target get
copied from /ports/xxx -> /imports/xxx.  If no arch-specific implementation
exists, then the generic one is copied which will throw the "unimplemented"
static assert.


Problems that need resolving:

1) How we handle multiple architectures.

Obviously, we could go with the following structure for installed druntime
installations:
  /usr/include/d/core         # Default target if no -mXX.
  /usr/include/d/x86_64/core  # Use this directory instead if -m64 is passed.

This kind of structure is already implemented in gdc, and is natural to the way
things are done within gcc's framework, but this I think would require compiler
changes for dmd to support.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------