A larger question is where such a feature would fit in the hierarchy of the important and urgent. I understand the sentiment that something seems naturally desirable to a group of folks, but there is no shortage of things to work on and we need to cull the list. -- Andrei

On 3/7/17 2:34 AM, Johan Engelen via dmd-internals wrote:
> On Tue, Mar 7, 2017 at 8:10 AM, Walter Bright via dmd-internals
> <dmd-internals@puremagic.com <mailto:dmd-internals@puremagic.com>> wrote:
>
>
>
>     I don't see the value in, for example, compiling Linux code from
>     Windows. As I said, it has never come up.
>
>
> I do this every time I work on Weka's code, and Weka's employees that
> are on Mac do this too.
> It is used when you have non-portable code that contains Linux-specific
> things, but you don't want to upload the code to a buildserver just to
> do semantic analysis.
>
> -Johan
>
>
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Tuesday, 7 March 2017 at 12:26:41 UTC, Andrei Alexandrescu wrote:
> A larger question is where such a feature would fit in the hierarchy of the important and urgent. I understand the sentiment that something seems naturally desirable to a group of folks, but there is no shortage of things to work on and we need to cull the list. -- Andrei
>
> On 3/7/17 2:34 AM, Johan Engelen via dmd-internals wrote:
>> On Tue, Mar 7, 2017 at 8:10 AM, Walter Bright via dmd-internals
>> <dmd-internals@puremagic.com <mailto:dmd-internals@puremagic.com>> wrote:
>>
>>
>>
>>     I don't see the value in, for example, compiling Linux code from
>>     Windows. As I said, it has never come up.
>>
>>
>> I do this every time I work on Weka's code, and Weka's employees that
>> are on Mac do this too.
>> It is used when you have non-portable code that contains Linux-specific
>> things, but you don't want to upload the code to a buildserver just to
>> do semantic analysis.
>>
>> -Johan
>>
>>
>>
>> _______________________________________________
>> dmd-internals mailing list
>> dmd-internals@puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-internals

There's no need to cull the list when some else *is* doing the work. The point is that LDC and probably GDC are already pretty close to fully supporting supporting cross-compilation and putting arbitrary limitations in the front-end, just because it is not an urgent goal for dmd is counter-productive for both compilers.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 7 March 2017 at 19:05, Petar Kirov [ZombineDev] via dmd-internals <dmd-internals@puremagic.com> wrote:
>
>
> There's no need to cull the list when some else *is* doing the work. The point is that LDC and probably GDC are already pretty close to fully supporting supporting cross-compilation and putting arbitrary limitations in the front-end, just because it is not an urgent goal for dmd is counter-productive for both compilers.
>

Pretty-close?  Support has been there for over a decade...
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 26 February 2017 at 18:01, Jacob Carlborg via dmd-internals <dmd-internals@puremagic.com> wrote:
> Hi,
>
> I would like to refactor the code in DMD for the Objective-C integration. I’m mostly interested in replacing the way used to determine if the Objective-C integration should be enabled or not.
>
> This is currently done in the makefile by either adding a file containing the code for the Objective-C integration or a stub implementation for the targets that does not support the Objective-C integration. Since this is determined at build time (of the compiler) this does not work well with cross-compiling, LDC have all targets enabled by default.
>
> I would like to change this to determine if the Objective-C integration should be enabled or not at runtime (of the compiler). I was thinking I could do that by having an interface with two classes implementing the interface. One which is used when the Objective-C integration should be enabled and one when it should be disabled. Example:
>
> __gshared Objc objc;
>
> void initialize()
> {
>     objc = global.params.hasObjectiveC ? new Supported : new Unsupported;
> }
>
> interface Objc
> {
>     void setObjc(ClassDeclaration cd);
> }
>
> final class Unsupported : Objc
> {
>     void setObjc(ClassDeclaration cd)
>     {
>         cd.error("Objective-C classes not supported");
>     }
> }
>
> final class Supported : Objc
> {
>     void setObjc(ClassDeclaration cd)
>     {
>         cd.objc.objc = true;
>     }
> }
>
> Does this sound like an acceptable solution or are there better alternatives? I’m also open to suggestions for better names for the classes.
>

IMO, at the very least it should be encapsulated into a struct like we have Target or Port, removing all the free functions.

At some point in the future, all global.params.isXXX should be moved to Target.  And hasObjectiveC should be encapsulated as an internal state of the Objc struct also.

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

> On 7 Mar 2017, at 13:26, Andrei Alexandrescu via dmd-internals <dmd-internals@puremagic.com> wrote:
> 
> A larger question is where such a feature would fit in the hierarchy of the important and urgent. I understand the sentiment that something seems naturally desirable to a group of folks, but there is no shortage of things to work on and we need to cull the list. -- Andrei


I started this discussion because I want to continue the work on the Objective-C support. Before doing that I would like to first have a good foundation. Taking the decision if the Objective-C support is enabled or not in the makefile (as it does today) is not a good solution in my opinion. Since both LDC and GDC supports cross-compiling (and hopefully DMD as well in the future) I thought it would be a good idea to move the decision to runtime (of the compiler).

-- 
/Jacob Carlborg

> On 7 Mar 2017, at 08:10, Walter Bright via dmd-internals <dmd-internals@puremagic.com> wrote:
> 
> I don't see the value in, for example, compiling Linux code from Windows. As I said, it has never come up.


A couple of reasons of why I think it should be a runtime check:

* It is a runtime check today, at least partly

* Today it’s possible to cross-compile on macOS to 32bit. If the check is only performed at compile-time it would be possible to use a 64bit compiler to compile for 32bit without getting any compile time errors (note that the Objective-C integration is not supported on 32bit)

* LDC and GDC are cross-compilers

Perhaps a bit far fetched, but one reason you _need_ to cross-compile on macOS is when targeting iOS, watchOS and tvOS devices which are all ARM devices. Of course, DMD doesn’t support ARM. But, when targeting the Simulator it will actually compile for x86 and not ARM, so it would be possible to use DMD for that.

-- 
/Jacob Carlborg
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 03/07/2017 08:10 AM, Walter Bright via dmd-internals wrote:
> On 3/6/2017 3:48 AM, Daniel Murphy wrote:
> I don't see the value in, for example, compiling Linux code from
> Windows. As I said, it has never come up.

That's a misjudgement, go get's a lot out of having full and simple cross-compilation support built-in. Makes packaging/releasing a swift and is one of the reasons it's getting a lot of traction.

Their support is also simpler than using different cross-compilers for each target, not sure if that's possible w/ GDC/LDC's multilibs.

Biggest hurdle seems to be cross-OS linking, not sure how to best address this. The go people typically use static linking to avoid that problem.

-Martin

Another really good example of cross compilation is x86 -> arm.  I don't have actual statistics to back it other than my own where essentially ALL of my arm development for the last 2ish years has been like that. Cross-compilation between platforms is increasingly the norm.  x86 to x86 is about the only place it isn't done.


On 3/25/2017 11:15 AM, Martin Nowak via dmd-internals wrote:
> On 03/07/2017 08:10 AM, Walter Bright via dmd-internals wrote:
>> On 3/6/2017 3:48 AM, Daniel Murphy wrote:
>> I don't see the value in, for example, compiling Linux code from
>> Windows. As I said, it has never come up.
> That's a misjudgement, go get's a lot out of having full and simple cross-compilation support built-in. Makes packaging/releasing a swift and is one of the reasons it's getting a lot of traction.
>
> Their support is also simpler than using different cross-compilers for each target, not sure if that's possible w/ GDC/LDC's multilibs.
>
> Biggest hurdle seems to be cross-OS linking, not sure how to best address this. The go people typically use static linking to avoid that problem.
>
> -Martin
>
>
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 03/05/2017 12:52 PM, Walter Bright via dmd-internals wrote:
> The stub file can be merged with the non-stub file, and use a compile time version conditional. No need for runtime dispatch.

Yes, let's put this in one file and use version (OSX) or version
(ObjectiveC) to enable support.
Would be great if we didn't have to adopt dmd docs build at completely
unrelated places.
https://github.com/dlang/dlang.org/pull/1830#issuecomment-316404375