On Saturday, 28 October 2017 at 00:05:53 UTC, codephantom wrote:
>
> At a minimum, I had to download 3.5GB of VS build tools just so I could compile a 64 bit D program (and it took me almost a whole day to work out the correct process).

At a minimum you'd better try WinSDK first, there should be all necessary tools. After all it is system's development kit, not some fancy junk.

> Is that a problem of D or VS?
>
> Is is it problem that D should accept, and just impose on it's users?
>

VS is standard for C++ on Windows. Period. Not much to discuss here.
Why we need MS native tools? Because D offers C++ FFI. See the connection? But who said that we compile/link using VS itself?

And again, DMD installer offers to install whole VS most likely because on Windows there is not that much experienced devs in the team. So this probably overlooked. Also this is why there are some *core* features that never(or almost never) worked on Windows but works for ages on linux, such as "DLL support" or my favorite "type information across DLL/process boundaries"...


Since you already on that wave, can you test Windows SDK installation and make DMD's sc.ini use the SDK?

On Saturday, 28 October 2017 at 01:42:52 UTC, evilrat wrote:
> Since you already on that wave, can you test Windows SDK installation and make DMD's sc.ini use the SDK?

nope. not me. I've had enough ;-)

I use FreeBSD.

I just wanted so see what effort I had to undertake to compile D into a 64bit binary on Windows - presuming I didn't want visual studio too...

Needless to say...I'm not impressed. And I'll leave it at that.

On Saturday, 28 October 2017 at 02:30:50 UTC, codephantom wrote:
> On Saturday, 28 October 2017 at 01:42:52 UTC, evilrat wrote:
>> Since you already on that wave, can you test Windows SDK installation and make DMD's sc.ini use the SDK?
>
> nope. not me. I've had enough ;-)
>
> I use FreeBSD.
>
> I just wanted so see what effort I had to undertake to compile D into a 64bit binary on Windows - presuming I didn't want visual studio too...
>
> Needless to say...I'm not impressed. And I'll leave it at that.

No problem. Actually there is a recent post in blog about D and VS where WinSDK is mentioned, might be interested to read - https://dlang.org/blog/2017/10/25/dmd-windows-and-c/


Some clarifications - VS projects(at least MS one's, i.e. C++ and C#) are just xml 'build scripts' for msbuild.exe, which itself don't have the knowledge about project or how to build them, it is plugins that provides such knowledge to it. So in this sense VS project properties editor is just a nice UI for editing build scripts. And when one hit the build button in VS it is just invokes msbuild with that script(project file). That's why we have WinSDK, MSBuild tools, and VS as separate downloads, and VS includes the former two.
More or less like that. This might be helpful for some users.

On Saturday, 28 October 2017 at 01:08:57 UTC, Mengu wrote:
> looks like d has a long way to go on freebsd as well.

I've had no issues with D in FreeBSD at all...

...and it's been a really smooth transition to D...so far...

I have D, Postgresql, and static C/C++ bindings working just fine...and that's really all I need..for now.

btw. The FreeBSD platform isn't even mentioned here:

https://insights.stackoverflow.com/survey/2017#technology-platforms

So I'm just glad it works at all..otherwise I'd have to choose between not using D, or using another platform...and neither choice is appealing.

On Saturday, October 28, 2017 02:48:00 evilrat via Digitalmars-d wrote:
> On Saturday, 28 October 2017 at 02:30:50 UTC, codephantom wrote:
> > On Saturday, 28 October 2017 at 01:42:52 UTC, evilrat wrote:
> >> Since you already on that wave, can you test Windows SDK installation and make DMD's sc.ini use the SDK?
> >
> > nope. not me. I've had enough ;-)
> >
> > I use FreeBSD.
> >
> > I just wanted so see what effort I had to undertake to compile D into a 64bit binary on Windows - presuming I didn't want visual studio too...
> >
> > Needless to say...I'm not impressed. And I'll leave it at that.
>
> No problem. Actually there is a recent post in blog about D and VS where WinSDK is mentioned, might be interested to read - https://dlang.org/blog/2017/10/25/dmd-windows-and-c/
>
>
> Some clarifications - VS projects(at least MS one's, i.e. C++ and
> C#) are just xml 'build scripts' for msbuild.exe, which itself
> don't have the knowledge about project or how to build them, it
> is plugins that provides such knowledge to it. So in this sense
> VS project properties editor is just a nice UI for editing build
> scripts. And when one hit the build button in VS it is just
> invokes msbuild with that script(project file). That's why we
> have WinSDK, MSBuild tools, and VS as separate downloads, and VS
> includes the former two.
> More or less like that. This might be helpful for some users.

At a previous job where we had both Linux and Windows builds of our libraries (though applications themselves tended to be single platform), I got so sick of dealing with VS and the builds not being consistent across platforms (since Linux used Makefiles, and those obviously had to be edited separately from the VS stuff) that I rewrote our build stuff so that it was all generated with cmake. Then editing the build was the same on both platforms, and building was _almost_ the same. I didn't even need to open up VS anymore - for configuration or for building. It was glorious.

I expect that it's the sort of thing that would annoy many Windows devs though, because the fact that the VS files were generated meant that you couldn't make changes in VS and have it stick (which from my perspective was great, but for a hardcore Windows person, probably not so much).

- Jonathan M Davis

On Saturday, October 28, 2017 02:50:39 codephantom via Digitalmars-d wrote:
> On Saturday, 28 October 2017 at 01:08:57 UTC, Mengu wrote:
> > looks like d has a long way to go on freebsd as well.
>
> I've had no issues with D in FreeBSD at all...
>
> ...and it's been a really smooth transition to D...so far...
>
> I have D, Postgresql, and static C/C++ bindings working just fine...and that's really all I need..for now.
>
> btw. The FreeBSD platform isn't even mentioned here:
>
> https://insights.stackoverflow.com/survey/2017#technology-platforms
>
> So I'm just glad it works at all..otherwise I'd have to choose between not using D, or using another platform...and neither choice is appealing.

FreeBSD generally works well, but it hasn't generally been handled quite as well as Linux - in part because of the auto-tester, and in part because a lot fewer people around here use FreeBSD.

I've sometimes had problems, because the autotester currently uses FreeBSD 8.4 (IIRC), and so breakage on recent versions of FreeBSD aren't always caught (though we're working towards getting the autotesters updated - there are a few tests that currently fail with newer versions of FreeBSD but not many). 32-bit in particular has more problems, since I think that most of us who do use FreeBSD are running the 64-bit version, so some of the problems weren't caught until Brad tried to upgrade the auto-tester.

Things are made worse for me by the fact that I run TrueOS, which is essentially a vetted snapshot of the development version of FreeBSD, so things break from time to time. At the moment, I'm hoping that

https://issues.dlang.org/show_bug.cgi?id=17596

gets sorted out before December, since the next update for the TrueOS stable branch is coming out then, and I expect that it will have the inode64 changes, which breaks dmd and pretty much any D program that deals with files. However, anyone running FreeBSD 11.x is in for a much smoother ride, and the fact that a few of us use TrueOS or FreeBSD CURRENT allows such problems to be caught before it becomes a problem for the release versions of FreeBSD. Getting the auto-tester updated will definitely help though.

- Jonathan M Davis

On Saturday, 28 October 2017 at 03:00:16 UTC, Jonathan M Davis wrote:
> ... I rewrote our build stuff so that it was all generated with cmake. Then editing the build was the same on both platforms, and building was _almost_ the same. I didn't even need to open up VS anymore - for configuration or for building. It was glorious.
>
> I expect that it's the sort of thing that would annoy many Windows devs though, because the fact that the VS files were generated meant that you couldn't make changes in VS and have it stick (which from my perspective was great, but for a hardcore Windows person, probably not so much).
>

Never heard of anyone who is annoyed by cmake/vs combo. Quite the opposite, there is an issue with "true" hardcore Linux devs who cannot into cmake. They stuck with autotools, which is not an option on Windows. This especially true for any C projects, and also the fact that we stuck with C89 on Windows. And another side of the problem is commercial middleware carp which distributed as VS projects only and only supports some "ancient" VS version, though I can't remember such examples.

On Saturday, October 28, 2017 03:45:02 evilrat via Digitalmars-d wrote:
> On Saturday, 28 October 2017 at 03:00:16 UTC, Jonathan M Davis
>
> wrote:
> > ... I rewrote our build stuff so that it was all generated with cmake. Then editing the build was the same on both platforms, and building was _almost_ the same. I didn't even need to open up VS anymore - for configuration or for building. It was glorious.
> >
> > I expect that it's the sort of thing that would annoy many Windows devs though, because the fact that the VS files were generated meant that you couldn't make changes in VS and have it stick (which from my perspective was great, but for a hardcore Windows person, probably not so much).
>
> Never heard of anyone who is annoyed by cmake/vs combo. Quite the opposite, there is an issue with "true" hardcore Linux devs who cannot into cmake. They stuck with autotools, which is not an option on Windows. This especially true for any C projects, and also the fact that we stuck with C89 on Windows. And another side of the problem is commercial middleware carp which distributed as VS projects only and only supports some "ancient" VS version, though I can't remember such examples.

The problem would be Windows devs who wanted to change any settings inside of VS. I don't think that it would have even worked to retain the file that's specific to the user, since it sits next to the normal VS project files, which were in a directory that would be deleted whenever a full rebuild was done. So, as long as you didn't need to configure any aspect of VS where the settings were saved in a file in that directory, you'd be fine, but something like your local debug settings for the project would probably be lost on a regular basis.

So, while someone who's more of a Linux dev is likely to be very much in favor of using cmake to control everything, a hardcore Windows dev who uses VS on a regular basis might not view it the same way. Personally, I think that most anyone dealing with VS would be better off using cmake to generate its project files than using VS to control that stuff (it is _so_ easy to do stuff like make it so that the debug and release builds are not in sync if you're configuring VS directly), but I wouldn't have dared to suggest it at my last job, which was a Windows-only shop. The folks there were too Windows-centric and too set in their ways for that to have gone over well at all, even though it likely would have fixed a number of our build-related problems.

- Jonathan M Davis

On Saturday, 28 October 2017 at 01:42:52 UTC, evilrat wrote:
> At a minimum you'd better try WinSDK first, there should be all necessary tools. After all it is system's development kit, not some fancy junk.

The Windows SDK hasn't included compilers since Windows 7.

Visual C++ is available as a NuGet package, which is just a .zip file. The 2017 version is ~650MB: https://www.nuget.org/packages/VisualCppTools.Community.VS2017Layout/

Unfortunately, it doesn't include the SDK headers or libs.

Bob

On 10/27/2017 1:06 AM, Jacob Carlborg via Digitalmars-d wrote:

> On 2017-10-27 04:34, Brad Roberts wrote:
>
>> Actually, one of the 3 macos boxes is using stock xcode tooling these days.  I specifically went that direction when setting up a new system that replaced one that died on me (well, it boots but if I actually _use_ it it crashes, sigh).
>>
>> So, but on the older osx releases (not positive the exact versions off the top of my head) there were issues that forced us back to an old gcc version rather than the default clang compiler.
>
> I haven't been using GCC in years and I never had any problems with compiling DMD using Clang.
>

The issues weren't compiling dmd but passing the full test suite. Both are required.