Thread overview | |||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
February 26, 2017 [dmd-internals] Refactoring of the Objective-C integration | ||||
---|---|---|---|---|
| ||||
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 Re: [dmd-internals] Refactoring of the Objective-C integration | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | 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 Re: [dmd-internals] Refactoring of the Objective-C integration | ||||
---|---|---|---|---|
| ||||
Posted in reply to Daniel Murphy | 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 Re: [dmd-internals] Refactoring of the Objective-C integration | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sebastian Wilzbach | 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 Re: [dmd-internals] Refactoring of the Objective-C integration | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | > 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 Re: [dmd-internals] Refactoring of the Objective-C integration | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | 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 Re: [dmd-internals] Refactoring of the Objective-C integration | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 Re: [dmd-internals] Refactoring of the Objective-C integration | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | > 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 Re: [dmd-internals] Refactoring of the Objective-C integration | ||||
---|---|---|---|---|
| ||||
Posted in reply to Daniel Murphy | 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 Re: [dmd-internals] Refactoring of the Objective-C integration | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright Attachments:
| 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
|
Copyright © 1999-2021 by the D Language Foundation