On Wednesday, March 07, 2012 23:07:11 Mars wrote:
> On Friday, 2 March 2012 at 11:53:56 UTC, Manu wrote:
> > Personally, I just want to be able to link like a normal
> > windows developer.
> > My code is C/C++, built with VC, and I want to link my D app
> > against those
> > libs using the VC linker, and debug with Visual Studio. This is
> > the
> > workflow I think the vast majority of Windows devs will expect,
> > and it
> > sounds simple enough. This is the only thing standing between
> > me using D
> > for any major projects, and just experimenting with the
> > language for
> > evaluation, or just academic interest.
> > 64bit is far less important to me personally, VisualC linker
> > compatibility
> > is the big one. I just want to link against my C code without
> > jumping
> > through lots of hoops.
> 
> That's exactly my problem... and although I love D, these hurdles made me take a step back, to C++, while I wait for this to change, so I can finally use D efficiently.
> 
> I'm sure this isn't a trivial task, but the problematic isn't new after all. Why hasn't it been addressed yet? In my eyes this should be a top priority, to make it easier for new users to get into D. Till this poll I actually believed the problem was that D isn't used much by Windows users.

I don' think that Walter really views it as much of a problem - or if he does, he didn't used to. Remember that he's used to an environment where he doesn't use Visual Studio or Microsoft's C++ compiler. And his customers use dmc just like he does (since they're his customers), so many of the people that he interacts with in the C/C++ world are not necessarily particularly Microsoft- centric on Windows.

Add to that the enormous task that it is to actually make dmd work with COFF or 64-bit or anything of the sort on Windows, and it's no wonder that it hasn't happened yet.

To be fair, there are plenty of other things that have needed to be done, and what we have for Windows does work, even if it's suboptimal. So, it's not all that unreasonable that the issue would be put off as long as it has been. And Walter _has_ been slowing working on porting optlink to C (the fact that it's written in assembly makes it really fast but hard to maintain and change), which would make it possible to then start porting stuff to 64-bit and considering COFF and stuff like that.

I expect that we'll get there eventually, but there's so much to do, and this particular issue is not only hard, but there's pretty much only one person currently qualified to do it, so it hasn't happened yet.

- Jonathan M Davis

On Saturday, 3 March 2012 at 11:44:54 UTC, Daniel Murphy wrote:
> Walter, how big is it really?  Small enough to be done as, say, a gsoc
> project?  Would you be interested in mentoring such a project?

I don't know whether it would really be a problem from a legal (Google) point of view, but having a GSoC student work on non-Open Source software seems strange at least.

David

On 8 March 2012 00:21, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Wednesday, March 07, 2012 23:07:11 Mars wrote:
> > On Friday, 2 March 2012 at 11:53:56 UTC, Manu wrote:
> > > Personally, I just want to be able to link like a normal
> > > windows developer.
> > > My code is C/C++, built with VC, and I want to link my D app
> > > against those
> > > libs using the VC linker, and debug with Visual Studio. This is
> > > the
> > > workflow I think the vast majority of Windows devs will expect,
> > > and it
> > > sounds simple enough. This is the only thing standing between
> > > me using D
> > > for any major projects, and just experimenting with the
> > > language for
> > > evaluation, or just academic interest.
> > > 64bit is far less important to me personally, VisualC linker
> > > compatibility
> > > is the big one. I just want to link against my C code without
> > > jumping
> > > through lots of hoops.
> >
> > That's exactly my problem... and although I love D, these hurdles made me take a step back, to C++, while I wait for this to change, so I can finally use D efficiently.
> >
> > I'm sure this isn't a trivial task, but the problematic isn't new after all. Why hasn't it been addressed yet? In my eyes this should be a top priority, to make it easier for new users to get into D. Till this poll I actually believed the problem was that D isn't used much by Windows users.
>
> I don' think that Walter really views it as much of a problem - or if he
> does,
> he didn't used to. Remember that he's used to an environment where he
> doesn't
> use Visual Studio or Microsoft's C++ compiler. And his customers use dmc
> just
> like he does (since they're his customers), so many of the people that he
> interacts with in the C/C++ world are not necessarily particularly
> Microsoft-
> centric on Windows.
>
> Add to that the enormous task that it is to actually make dmd work with
> COFF
> or 64-bit or anything of the sort on Windows, and it's no wonder that it
> hasn't happened yet.
>
> To be fair, there are plenty of other things that have needed to be done,
> and
> what we have for Windows does work, even if it's suboptimal. So, it's not
> all
> that unreasonable that the issue would be put off as long as it has been.
> And
> Walter _has_ been slowing working on porting optlink to C (the fact that
> it's
> written in assembly makes it really fast but hard to maintain and change),
> which would make it possible to then start porting stuff to 64-bit and
> considering COFF and stuff like that.
>

Is it possible to just fix the compiler to output COFF objects *without*
touching optlink at all?
I'm not interested in using optlink with this feature, I intend to link
with Visual Studio, that's the whole point. So ignoring optlink, that's a
major slice of work taken out of the equation...
Maybe it would be nice to support optlink in future, but it seems the
priority is backwards.



> I expect that we'll get there eventually, but there's so much to do, and
> this
> particular issue is not only hard, but there's pretty much only one person
> currently qualified to do it, so it hasn't happened yet.
>
> - Jonathan M Davis
>

On Thursday, March 08, 2012 11:12:01 Manu wrote:
> Is it possible to just fix the compiler to output COFF objects *without* touching optlink at all?

I have no idea. In principle, I would think so, but I don't know. But dmd would have to be altered so that you could choose the object format rather than being simply switched over to COFF regardless. Ideally, it would be modular enough to be able to make it output any format you like with plugins or somesuch, but I have no idea how it's designed. And therein is the largest problem regardless. Walter is probably the only person who knows the backend well enough to do anything like this. So, regardless of what the situation with optlink is, it's almost certainly going to require Walter, who's busy with plenty of other stuff which is also very important.

If someone could make the changes themselves and create a pull request for it, then we could probably get COFF, but that would require someone knowledgeable enough to do that, and I don't think that anyone other than Walter really is. If someone other than Walter is going to do it, then they've got a lot to learn, and no one has taken the time to do that.

- Jonathan M Davis

On Thursday, March 08, 2012 09:45:34 David Nadlinger wrote:
> On Saturday, 3 March 2012 at 11:44:54 UTC, Daniel Murphy wrote:
> > Walter, how big is it really?  Small enough to be done as, say,
> > a gsoc
> > project?  Would you be interested in mentoring such a project?
> 
> I don't know whether it would really be a problem from a legal (Google) point of view, but having a GSoC student work on non-Open Source software seems strange at least.

I though that GSoC had a list of licenses which were acceptable for GSoC projects - all of which are open source license of one variety or another.

- Jonathan M Davis

On Thursday, 8 March 2012 at 09:25:19 UTC, Jonathan M Davis wrote:
> On Thursday, March 08, 2012 09:45:34 David Nadlinger wrote:
>> On Saturday, 3 March 2012 at 11:44:54 UTC, Daniel Murphy wrote:
>> > Walter, how big is it really?  Small enough to be done as, say,
>> > a gsoc
>> > project?  Would you be interested in mentoring such a project?
>> 
>> I don't know whether it would really be a problem from a legal
>> (Google) point of view, but having a GSoC student work on
>> non-Open Source software seems strange at least.
>
> I though that GSoC had a list of licenses which were acceptable for GSoC
> projects - all of which are open source license of one variety or another.
>
> - Jonathan M Davis

That's his point; the backend isn't open source.

"David Nadlinger" <see@klickverbot.at> wrote in message news:refqfgvqmhafcmeljhcr@forum.dlang.org...
> On Saturday, 3 March 2012 at 11:44:54 UTC, Daniel Murphy wrote:
>> Walter, how big is it really?  Small enough to be done as, say, a gsoc project?  Would you be interested in mentoring such a project?
>
> I don't know whether it would really be a problem from a legal (Google) point of view, but having a GSoC student work on non-Open Source software seems strange at least.
>
> David

Didn't think of that... I'm not sure what the license on the object generation code is, the files are not in the backend folder but they are conceptually part of the backend, and not useful to other compilers like the frontend is.

"Manu" <turkeyman@gmail.com> wrote in message
news:mailman.223.1331197934.4860.digitalmars-d@puremagic.com...
On 8 March 2012 00:21, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> Is it possible to just fix the compiler to output COFF objects *without*
> touching optlink at all?
> I'm not interested in using optlink with this feature, I intend to link
> with Visual Studio, that's the whole point. So ignoring optlink, that's a
> major slice of work taken out of the equation...
> Maybe it would be nice to support optlink in future, but it seems the
> priority is backwards.

Yes, it is, but then you still won't be able to link omf and coff object files/libraries together, meaning you need a coff version of druntime/phobos/any other d libraries, and you can't use the c runtime made by dmc etc.

Ideally everything would work together, and with a tool that can be bundled with D.

On 8 March 2012 15:55, Daniel Murphy <yebblies@nospamgmail.com> wrote:

> "Manu" <turkeyman@gmail.com> wrote in message
> news:mailman.223.1331197934.4860.digitalmars-d@puremagic.com...
> On 8 March 2012 00:21, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> > Is it possible to just fix the compiler to output COFF objects *without*
> > touching optlink at all?
> > I'm not interested in using optlink with this feature, I intend to link
> > with Visual Studio, that's the whole point. So ignoring optlink, that's a
> > major slice of work taken out of the equation...
> > Maybe it would be nice to support optlink in future, but it seems the
> > priority is backwards.
>
> Yes, it is, but then you still won't be able to link omf and coff object files/libraries together, meaning you need a coff version of druntime/phobos/any other d libraries, and you can't use the c runtime made by dmc etc.
>

That's fine, I would use the mscrt (required to link with all the rest of
my code anyway), and as soon as the feature is available, you can bet your
boots that OMF will cease to exist in windows library distributions
instantly.
When was the last time you saw a closed-source windows library ship with .a
files? Windows library distributions would be VC compatible COFF objects
within days.

Ideally everything would work together, and with a tool that can be bundled
> with D.
>

Optlink is bundled with D, I presume OMF would remain an option as a
standalone 'complete package', but realistically, I don't think virtually
any windows users would use it once they can link with VS.
The kind of Windows user that might use OMF+optlink is the same kind of
user that would be perfectly happy, maybe even prefer to use GDC/LDC.

On 2012-03-08 10:12, Manu wrote:
> On 8 March 2012 00:21, Jonathan M Davis <jmdavisProg@gmx.com
> <mailto:jmdavisProg@gmx.com>> wrote:
>
>     On Wednesday, March 07, 2012 23:07:11 Mars wrote:
>      > On Friday, 2 March 2012 at 11:53:56 UTC, Manu wrote:
>      > > Personally, I just want to be able to link like a normal
>      > > windows developer.
>      > > My code is C/C++, built with VC, and I want to link my D app
>      > > against those
>      > > libs using the VC linker, and debug with Visual Studio. This is
>      > > the
>      > > workflow I think the vast majority of Windows devs will expect,
>      > > and it
>      > > sounds simple enough. This is the only thing standing between
>      > > me using D
>      > > for any major projects, and just experimenting with the
>      > > language for
>      > > evaluation, or just academic interest.
>      > > 64bit is far less important to me personally, VisualC linker
>      > > compatibility
>      > > is the big one. I just want to link against my C code without
>      > > jumping
>      > > through lots of hoops.
>      >
>      > That's exactly my problem... and although I love D, these hurdles
>      > made me take a step back, to C++, while I wait for this to
>      > change, so I can finally use D efficiently.
>      >
>      > I'm sure this isn't a trivial task, but the problematic isn't new
>      > after all. Why hasn't it been addressed yet? In my eyes this
>      > should be a top priority, to make it easier for new users to get
>      > into D. Till this poll I actually believed the problem was that D
>      > isn't used much by Windows users.
>
>     I don' think that Walter really views it as much of a problem - or
>     if he does,
>     he didn't used to. Remember that he's used to an environment where
>     he doesn't
>     use Visual Studio or Microsoft's C++ compiler. And his customers use
>     dmc just
>     like he does (since they're his customers), so many of the people
>     that he
>     interacts with in the C/C++ world are not necessarily particularly
>     Microsoft-
>     centric on Windows.
>
>     Add to that the enormous task that it is to actually make dmd work
>     with COFF
>     or 64-bit or anything of the sort on Windows, and it's no wonder that it
>     hasn't happened yet.
>
>     To be fair, there are plenty of other things that have needed to be
>     done, and
>     what we have for Windows does work, even if it's suboptimal. So,
>     it's not all
>     that unreasonable that the issue would be put off as long as it has
>     been. And
>     Walter _has_ been slowing working on porting optlink to C (the fact
>     that it's
>     written in assembly makes it really fast but hard to maintain and
>     change),
>     which would make it possible to then start porting stuff to 64-bit and
>     considering COFF and stuff like that.
>
>
> Is it possible to just fix the compiler to output COFF objects *without*
> touching optlink at all?
> I'm not interested in using optlink with this feature, I intend to link
> with Visual Studio, that's the whole point. So ignoring optlink, that's
> a major slice of work taken out of the equation...
> Maybe it would be nice to support optlink in future, but it seems the
> priority is backwards.

DMD would need to be compatible with the Microsoft linker and runtime as well, that is, except from outputting object file in the correct format.


-- 
/Jacob Carlborg