[feature request] don't pollute PATH with mingw toolchain

[rkitover]

The mingw toolchain, compiler, pkg-config, etc.. is in the dist bin folder and so is in your global PATH if you have strawberry in your PATH.

This can cause issues with build tools such as cmake, which find this version of the mingw gcc, pkg-config, etc.; when the user may be wanting to use another toolchain in their PATH such as their own version of mingw or Visual Studio.

What I propose is that the mingw toolchain be stored in a different folder and only added to the PATH on the invocation of a module build toolchain: EU::MM, Module::Build, etc..

I don't honestly know the feasibility of this, what kind of hooks would need to go where.

[LeeThompson]

Strawberry might be able to use "setlocal" at the top of any compiler batch file that would allow PATH and other environment variables to be used as normal but which all go away after the batch file exits.

[kmx]

IMO removing c:\strawberry\c\bin from PATH will break a lot of things.

[rkitover]

The idea is to have it in the PATH for things that need it, started from e.g. some wrapper like EUMM etc.., and not in the user's PATH.

[kmx]

In that case it seems to be rather a feature request for EUMM

[rkitover]

Ok, but do you understand what the problem is. Try running e.g. cmake for a project from powershell with the default strawberry PATH entries, it will find all the mingw crap instead of the user's intended toolchain.

[rkitover]

An update on this. The problem is actually not as bad as I originally thought.

With Strawberry and MinGW installed from chocolatey, the chocolatey MinGW takes precedence in the PATH, with anything missing like gmake being picked up from strawberry/c/bin.

I built and installed an XS module with the chocolatey MinGW in the PATH with no issues.

As for cmake, while it will default to using the MinGW toolchain, simply specifying -DCMAKE_C_COMPILER=cl will make it select the Visual Studio toolchain instead. I will follow up with the cmake project about this default.

Likewise, specifying -DCMAKE_C_COMPILER=gcc will make it select the mingw toolchain, the chocolatey one in this case.

I still think this is bad, but at least not bad enough for me to avoid installing Strawberry entirely.

[sisyphus]

If you're worried about having Strawberry always in your path, install the portable version to the location of your choice.
That location is prepended to the PATH only when portableshell.bat (which is located in the "location of your choice") is executed.

I really don't see any need for Strawberry to do anything differently.

The practice of having the msi install append the relevant directories to the PATH is a long-established one.
If there's already an identical item (eg make, or pk-config, or gcc) in the PATH, then someone must have put it there - and the intent therefore is that the pre-existing item be used in preference to the one provided by Strawberry.

This contrasts with the portable version's portableshell.bat which puts everything at the beginning of the PATH.
In this case, the view is that the user is accepting everything that Strawberry provides.

I think the user should accept responsibility for taking care of these issues when they arise.
It's not always pretty - I can recall renaming Strawberry's pkg-config to pkg-config-hide just to get it out of the way, so the MSYS2 utility of the same name would be used.

Cheers,
Rob

[rkitover]

The issue is having a whole MinGW toolchain in your global PATH, rather than just perl and perl tools like perldoc, which is what people would expect. This can cause all kinds of problems with other tools, and is only done so that perl modules can build themselves. Perl modules should be able to build themselves without doing this.

[genio]

This is not an issue, but a requirement for Perl on Windows. In the unfortunate event that you have an alternate MinGW installed, you will have to be careful about your environment. There's no other way for Perl to function on Windows.

Please close this as there's simply no other way. Your work-around is to use the Portable installs and handle your own PATH how you like, but for the masses, this is how things have to be.

Perl use requires XS modules and third party libraries for developers to be able to write code. XS modules and those third-party libraries require MinGW on Windows as that's what Strawberry is built on. They require that the versions of the compiler used to build Perl and the the ones building the XS/libraries to match up enough that things behave well.

[genio]

You can yank the C compiler out of your own PATH unless you're installing things if that's your preference. However, some FFI modules and others will misbehave if there's no compiler available. https://metacpan.org/pod/FFI::Platypus::Bundle for example

[rkitover]

This is not an issue, but a requirement for Perl on Windows. In the unfortunate event that you have an alternate MinGW installed, you will have to be careful about your environment. There's no other way for Perl to function on Windows.

I respectfully disagree. Perl functions just fine without a compiler, for things involving perl and not installing modules. For the 99% of cases anyway, not including the use case you mentioned.

Quite a lot of people also use Perl as just a tool and don't even care about any non-core modules, many of which come pre-installed with Strawberry anyway.

When I was testing this, I actually had to spend some time searching for an XS module to build, because everything I tried was already pre-installed.

Please close this as there's simply no other way. Your work-around is to use the Portable installs and handle your own PATH how you like, but for the masses, this is how things have to be.

"This is how things have to be" why? There are many other simple alternatives to sticking a non-standard MinGW toolchain in the system global PATH by default. Which is actually quite rude. That is the actual issue.

For example, a shortcut could be installed for using cpan tools that does this. This is what Visual Studio does, I modify my own PowerShell profile to add Visual Studio tools to my PATH.

Or it could be an option that defaults to off, the user could easily modify their own PATH.

Or it could be a separate package entirely, with its own shortcut, etc..

Perl use requires XS modules and third party libraries for developers to be able to write code. XS modules and those third-party libraries require MinGW on Windows as that's what Strawberry is built on. They require that the versions of the compiler used to build Perl and the the ones building the XS/libraries to match up enough that things behave well.

Python on Windows is in a similar situation, it is built with Visual Studio and requires Visual Studio installed to build extensions. But they do not do this for you automatically and stick it in the PATH, though they easily could.

For that matter, why is Strawberry incompatible with the standard MinGW toolchain? I should be able to run something like:

choco install -y StrawberryPerl mingw

and have everything work.

And when I tried everything did in fact work with the standard MinGW gcc at least, some other things like gmake it does not come with.

Feel free to close this, I don't care about this that much, and I have a way to deal with it for myself which I described above, I just think it's wrong, from the perspective of Strawberry being a well-behaved Windows tool and development tool.

[genio]

It matters what version of MinGW the version of Strawberry you're using was built with. Many of them around that are installable on your version of Windows. They're not all built with the same MinGW. That version of MinGW from chocolatey would not work with, say, Strawberry Perl 5.16.

This isn't Python and wasn't built with Visual Studio, so that's not a great comparison. The installer for Strawberry installs a binary of the language as it was built at the time of release. In order to help you with all of the things I mentioned, it provides the packaged up MinGW it used as well.

Again, the fix here is to remove things out of the PATH that you don't want or to use the Portables and only put on the PATH what you want.

[rkitover]

It's true that the path is easily removable in your own environment, for example putting this line into your PowerShell $profile will do it:

$env:PATH = ($env:PATH -split ';' | ?{ $_ -notmatch '\\Strawberry\\c\\bin$' }) -join ';'

[boxerab]

Putting strawberry perl in the path is also a problem for me, as it adds it's own pkg-config binary, and I have my own version of pkg-config, so it messes up my GStreamer build. It should at least be an option during install, with default being to NOT add it to the path.