Live data from Hacker News

Cross-compiling binaries for Windows is easier than building natively

gist.github.com

111–120 of 349 posts

Re: Cross-compiling binaries for Windows is easier than building natively

#111
post #95

Earlier quoted context omitted.

It's interesting how people assume that their world is everyone else's... It's easy to forget that there are billions of people for whom $45 is a massive investment, and that SSD isn't so conveniently available even if they have the money. I know I got into programming on a mix of graphing calculators and thrown out PCs, and I also distinctly remember having to work around the download sizes of tooling because I was…

I’d say the part where the gp specifically said ssd invalidates your point __in this particular situtation__ because a person worried about their budget wouldn’t splurge on an ssd. I also, after a cursory search, have found that the cheapest hard drives are around $25 USD. While $20 isn’t nothing, it also isn’t budget-breaking.

... what? You think someone stretching their money for an SSD somehow indicates that they're not worried about their budget?

Here's a hint: if they had the budget and availability they'd just get a bigger SSD and not write that comment.

-

Obviously, due to some aspect of their circumstance, be it availability, cost, download speeds, etc. the size of the toolkit is problematic.

I mean there's no intrinsic size for a development toolkit, but I don't know anyone who'd say 60GBs of data is a small development toolkit when as others have pointed out, there are older versions of the same Windows toolchains that still complete the same function and manage to take a fraction of the space...

Re: Cross-compiling binaries for Windows is easier than building natively

#112
>I'm still blown away that they literally made the .NET team revert the dotnet watch PR at the last minute, so that they could sell it as a feature.

This is not even true. Due to limited resources they wanted to cut scope of what the .NET 6 update included and they thought that it would be okay to delay the dotnet watch feature because most people would still have hot reloading from using Visual Studio.

The PR for bringing back the hot reload code was merged 3 days after the PR for removing it.

https://devblogs.microsoft.com/dotnet/net-hot-reload-support...

Re: Cross-compiling binaries for Windows is easier than building natively

#113

Configure autocrlf in what way? I don't want git to change my files, and I don't know what problems they're talking about.

If you have some developers using window, and other developers using anything else, without some kind of line ending normalization, then you will end up with inconsistent line endings, possibly in the same file, and potentially diffs and commits where every line in a file is changed from one line ending to another.

Re: Cross-compiling binaries for Windows is easier than building natively

#114
post #62

Earlier quoted context omitted.

> What's the standard for being an "actual Windows user"? I think you misread that line.

Their message originally read "Actual Windows developers know NTFS has Symbolic Links"

So it did say "developers" and not "users"?

I think they misread the line.

(Whether it was right or not, so you don't need to tell me anything about that.)

Re: Cross-compiling binaries for Windows is easier than building natively

#115
post #14

It is. I generate the Windows executables for a program by cross-compiling Rust on Linux. Then test with Wine. The Rust crates are cross-platform enough that I don't have to special case platforms. This is easier than having a Windows machine. The only current headache is that there's no pure Rust bundler, to make ".msi" or ".msix" installer files. If you dump the legacy OS stuff, it gets easier.

Good news is winget will soon support single binaries so that is one option.

Can you link to info about this? I can't find much in a quick Google search

Re: Cross-compiling binaries for Windows is easier than building natively

#116
I agree that symlinks cause more trouble then is needed on any platform. Sadly, only Node really likes to use them to optimise the store of packages

Personally, I don't have major issues compiling things on Windows for other platforms (macOs, Win32, Android, Linux). Only awkward thing is designing UIs

Re: Cross-compiling binaries for Windows is easier than building natively

#118

Now try building a "portable" binary that runs on a version of Linux older than yours.

If you want to build binaries for a distro, build in that distro. If that distro has a Docker image, it's as simple as:

    docker run -v "$PWD:/src" olddistro:version /src/build.sh
$dayjob supports distros as old as CentOS 7 and as new as Ubuntu 22.04 this way.

Compiling on one distro and then expecting it to work on another distro is a foolhardy errand. Libraries have different versions, different paths (eg /usr/lib vs /usr/lib64 vs /usr/lib/x86_64-linux-gnu/ vs...), and different compile-time configuration (eg openssl engines directory) across distros.

Re: Cross-compiling binaries for Windows is easier than building natively

#119
post #21

For me SDK sizes are showstopper. Mingw packages are probably 100-200 Mb total. To build anything native one has to install Windows (20+Gb in modern version and then Visual Studio 40+Gb). Not so easy to fit it all on an SSD drive. Xcode also have this problem now. 8Gb for Xcode 7 is manageable. But why 70Gb for Xcode 11?

There's tooling that mostly avoids this. https://github.com/Jake-Shadle/xwin

This is a utility that fixes a lot of the cross-compiling issues for windows by giving you a portable, unfucked naming, and not-massive SDK. It's the same SDK you get when you install MSVC but it's only a few hundred megs and the names are consistent even with all of Windows' fucked up tooling.

The only caveat is you need to provide your own compiler, in this case clang is often the best option.

Re: Cross-compiling binaries for Windows is easier than building natively

#120
post #95

Earlier quoted context omitted.

I’d say the part where the gp specifically said ssd invalidates your point __in this particular situtation__ because a person worried about their budget wouldn’t splurge on an ssd. I also, after a cursory search, have found that the cheapest hard drives are around $25 USD. While $20 isn’t nothing, it also isn’t budget-breaking.

... what? You think someone stretching their money for an SSD somehow indicates that they're not worried about their budget? Here's a hint: if they had the budget and availability they'd just get a bigger SSD and not write that comment. - Obviously , due to some aspect of their circumstance, be it availability, cost, download speeds, etc. the size of the toolkit is problematic. I mean there's no intrinsic size for a…

What I’m saying is the delta between a very cheap hdd and an ssd is 20 bucks.

This whole assuming everyone is destitute is getting rather tiring.

Post reply on HN