digitalmars.D.bugs - [Issue 11666] New: Separate each platform's port to its own folder/file: aka "if version{} else version {}" getting out of control
- d-bugmail puremagic.com (44/44) Dec 02 2013 https://d.puremagic.com/issues/show_bug.cgi?id=11666
- d-bugmail puremagic.com (15/15) Dec 03 2013 https://d.puremagic.com/issues/show_bug.cgi?id=11666
- d-bugmail puremagic.com (12/12) Dec 03 2013 https://d.puremagic.com/issues/show_bug.cgi?id=11666
- d-bugmail puremagic.com (7/9) Dec 03 2013 https://d.puremagic.com/issues/show_bug.cgi?id=11666
- d-bugmail puremagic.com (15/24) Dec 04 2013 https://d.puremagic.com/issues/show_bug.cgi?id=11666
- d-bugmail puremagic.com (59/79) Dec 05 2013 https://d.puremagic.com/issues/show_bug.cgi?id=11666
- d-bugmail puremagic.com (9/12) Dec 05 2013 https://d.puremagic.com/issues/show_bug.cgi?id=11666
- d-bugmail puremagic.com (10/10) Feb 26 2014 https://d.puremagic.com/issues/show_bug.cgi?id=11666
- d-bugmail puremagic.com (7/8) Feb 26 2014 https://d.puremagic.com/issues/show_bug.cgi?id=11666
- d-bugmail puremagic.com (8/12) Mar 02 2014 https://d.puremagic.com/issues/show_bug.cgi?id=11666
- d-bugmail puremagic.com (7/7) Mar 02 2014 https://d.puremagic.com/issues/show_bug.cgi?id=11666
https://d.puremagic.com/issues/show_bug.cgi?id=11666 Summary: Separate each platform's port to its own folder/file: aka "if version{} else version {}" getting out of control Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: druntime AssignedTo: nobody puremagic.com ReportedBy: slavo5150 yahoo.com --- I'm attempting a port of the D Runtime to a new platform, and currently studying the D Runtime codebase. I find that the "if version{} else version {}" is not so eloquently employed, and as the list of D Runtime ports grow, this is going to get out of control (if it's not already). Ian Buclaw posted a recommendation here: http://forum.dlang.org/thread/fdsovuxnffmnpqhfmpts forum.dlang.org#post-mailman.1526.1333966829.4860.digitalmars-d:40puremagic.com Repeated here in case the original gets lost: ** 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. 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. ** end quote ** I'm filing this issue to hopefully bring attention to this and foster gradual change. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 02 2013
https://d.puremagic.com/issues/show_bug.cgi?id=11666 Iain Buclaw <ibuclaw ubuntu.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ibuclaw ubuntu.com Thanks Mike. I will add onto my quote from 18 months ago: Splitting architectures and platforms into separate files won't stop the code duplication, but it will make it more manageable for maintainers of the ports. eg: I've found a bug on MIPS32 where types mismatch between D and C runtime, I know to look under /ports/mips to find the declaration. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 03 2013
https://d.puremagic.com/issues/show_bug.cgi?id=11666 Martin Nowak <code dawg.eu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |code dawg.eu I agree with this and it's a know limitation of the current structure. But until someone figures out a good layout we can at least continue to work on ports. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 03 2013
https://d.puremagic.com/issues/show_bug.cgi?id=11666But until someone figures out a good layout we can at least continue to work on ports.And implements it :). -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 03 2013
https://d.puremagic.com/issues/show_bug.cgi?id=11666** 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? -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 04 2013
https://d.puremagic.com/issues/show_bug.cgi?id=11666I'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: 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: -------** 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?
Dec 05 2013
https://d.puremagic.com/issues/show_bug.cgi?id=116663) The platform versioning shall remain in place, leaving only architectural differences to be thrown under /portSlight amendment to that statement: If there are no differences between architectures. It shall be left as a common implementation for all targets supported by that platform. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 05 2013
https://d.puremagic.com/issues/show_bug.cgi?id=11666 Andrei Alexandrescu <andrei erdani.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrei erdani.com PST --- Is anyone working on this? -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 26 2014
https://d.puremagic.com/issues/show_bug.cgi?id=11666Is anyone working on this?It's on my long TODO list. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 26 2014
https://d.puremagic.com/issues/show_bug.cgi?id=11666OK, anyone interested, get reviewing and lets agree a workable solution. https://github.com/D-Programming-Language/druntime/pull/731 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------Is anyone working on this?It's on my long TODO list.
Mar 02 2014
https://d.puremagic.com/issues/show_bug.cgi?id=11666 --- https://github.com/D-Programming-Language/druntime/pull/732 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 02 2014