Jump to page: 1 2
Thread overview
[dmd-internals] Refactoring of the Objective-C integration
Feb 26, 2017
Jacob Carlborg
Feb 27, 2017
Daniel Murphy
Mar 05, 2017
Sebastian Wilzbach
Mar 05, 2017
Walter Bright
Mar 05, 2017
Jacob Carlborg
Mar 06, 2017
Walter Bright
Mar 06, 2017
Daniel Murphy
Mar 07, 2017
Walter Bright
Mar 07, 2017
Johan Engelen
Mar 07, 2017
Iain Buclaw
Mar 07, 2017
Jacob Carlborg
Mar 12, 2017
Jacob Carlborg
Mar 25, 2017
Martin Nowak
Mar 25, 2017
Brad Roberts
Mar 06, 2017
Jacob Carlborg
Jul 19, 2017
Martin Nowak
Mar 07, 2017
Iain Buclaw
February 26, 2017
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.

—
/Jacob Carlborg
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals
February 28, 2017
IMO it should just be inlined in the appropriate places in the regular frontend code, like we do for C++ support.  Either it's a first class feature, or it should be removed, I don't see much point in going half-way like we have.

Not that I'd bet on Walter merging that...

Using inheritance for this feels clumsy, mostly because (IIRC) one of the classes is going to be near-trivial.  Maybe it would be better to just if/error on hasObjectiveC in each function?  Maybe not.

I am in favor of moving compile-time decisions to runtime, so implementation specifics aside I support the goal.

On Mon, Feb 27, 2017 at 4:01 AM, 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.
>
> > /Jacob Carlborg
> _______________________________________________
> 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
March 05, 2017
FWIW the stubbing also creates pain on the tooling end as these files need to be manually excluded on all depending pipelines.
One example is the new documentation build of DDMD which for the time being is kinda empty:

DDoc: https://dlang.org/phobos-prerelease/ddmd_objc_stubs.html
DDox: https://dlang.org/library-prerelease/ddmd/objc.html

(though of course this could be solved by "ddocing" the stubs)

> I am in favor of moving compile-time decisions to runtime, so
> implementation specifics aside I support the goal.

+1

On 2017-02-27 15:09, Daniel Murphy via dmd-internals wrote:
> IMO it should just be inlined in the appropriate places in the regular
> frontend code, like we do for C++ support.  Either it's a first class
> feature, or it should be removed, I don't see much point in going
> half-way like we have.
> 
> Not that I'd bet on Walter merging that...
> 
> Using inheritance for this feels clumsy, mostly because (IIRC) one of
> the classes is going to be near-trivial.  Maybe it would be better to
> just if/error on hasObjectiveC in each function?  Maybe not.
> 
> I am in favor of moving compile-time decisions to runtime, so
> implementation specifics aside I support the goal.
> 
> On Mon, Feb 27, 2017 at 4:01 AM, 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.
>> 
>> >> /Jacob Carlborg
>> _______________________________________________
>> 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
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals
March 05, 2017

On 3/4/2017 11:38 PM, Sebastian Wilzbach via dmd-internals wrote:
> FWIW the stubbing also creates pain on the tooling end as these files need to be
> manually excluded on all depending pipelines.

We already do this for libelf.d, etc. I don't recall it ever being an issue.

Target dependent object file generation does not use a runtime switch, either.

The stub file can be merged with the non-stub file, and use a compile time version conditional. No need for runtime dispatch.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals
March 05, 2017
> On 5 Mar 2017, at 12:52, Walter Bright via dmd-internals <dmd-internals@puremagic.com> wrote:
> 
> We already do this for libelf.d, etc. I don't recall it ever being an issue.
> 
> Target dependent object file generation does not use a runtime switch, either.
> 
> The stub file can be merged with the non-stub file, and use a compile time version conditional. No need for runtime dispatch.

How do you see cross-compiling working when it’s a compile time decision (compiling the compiler)? As far as I understand, it only works for LDC because they’re not using the same makefiles as DMD does.

-- 
/Jacob Carlborg


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

On 3/5/2017 3:57 AM, Jacob Carlborg wrote:
> How do you see cross-compiling working when it’s a compile time decision
> (compiling the compiler)? As far as I understand, it only works for LDC
> because they’re not using the same makefiles as DMD does.

I don't see a need to compile OSX executables from Windows, Linux or FreeBSD. I don't recall it ever coming up.

DMD is not currently set up to cross compile that way, because the object file and library file code is a compile time switch. Making O-C a run time switch would still not make it a cross compiler.

The stub file is still pointless extra complexity, though, and using a compile time version will enable it to be merged with the non-stub file. It'd be a nice improvement.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals
March 06, 2017
This change alone is obviously not sufficient, and OSX is probably the target I'm least interested in....

But choosing targets at runtime does make cross-compiling much easier, and should be something we're working towards?  Or do you disagree?

On Mon, Mar 6, 2017 at 10:21 PM, Walter Bright via dmd-internals <dmd-internals@puremagic.com> wrote:
>
>
> On 3/5/2017 3:57 AM, Jacob Carlborg wrote:
>>
>> How do you see cross-compiling working when it’s a compile time decision (compiling the compiler)? As far as I understand, it only works for LDC because they’re not using the same makefiles as DMD does.
>
>
> I don't see a need to compile OSX executables from Windows, Linux or FreeBSD. I don't recall it ever coming up.
>
> DMD is not currently set up to cross compile that way, because the object file and library file code is a compile time switch. Making O-C a run time switch would still not make it a cross compiler.
>
> The stub file is still pointless extra complexity, though, and using a compile time version will enable it to be merged with the non-stub file. It'd be a nice improvement.
>
> _______________________________________________
> 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
March 06, 2017
> On 6 Mar 2017, at 12:21, Walter Bright <walter@digitalmars.com> wrote:
> 
> I don't see a need to compile OSX executables from Windows, Linux or FreeBSD. I don't recall it ever coming up.
> 
> DMD is not currently set up to cross compile that way, because the object file and library file code is a compile time switch. Making O-C a run time switch would still not make it a cross compiler.
> 
> The stub file is still pointless extra complexity, though, and using a compile time version will enable it to be merged with the non-stub file. It'd be a nice improvement.

Some of the checks are already runtime checks [1]. Which was changed in this PR [2]. Keep in mind that LDC is a cross-compiler (not sure about GDC).

[1] https://github.com/dlang/dmd/blob/master/src/ddmd/objc.d#L231 [2] https://github.com/dlang/dmd/pull/5641

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

On 3/6/2017 3:48 AM, Daniel Murphy wrote:
> But choosing targets at runtime does make cross-compiling much easier,
> and should be something we're working towards?  Or do you disagree?

I don't see the value in, for example, compiling Linux code from Windows. As I said, it has never come up.

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals
March 07, 2017
On Tue, Mar 7, 2017 at 8:10 AM, 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.
>

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


« First   ‹ Prev
1 2