Path pretty much hijacked

[mfinnis]

After installing the latest compiler I've noticed a number of programs have stopped working. On investigation it seems that my path environmental variable is too long and is being truncated (2047 characters). What is making it too long is the, very nearly, 1000 characters taken up by path elements inserted at the start of the path pointing to various Intel shared directories. Is this really necessary? Isn't it a bit greedy taking nearly a half of the path variable? Can't App Paths be used to reduce the reliance on the path variable?

[TimP]

I too would wish that the Intel software tools could minimize their entries on system path and clean them out when uninstalling.  It's too difficult using the basic Windows tools to see and correctly remove obsoleted entries.  This punishes the casual user for agreeing to install each update.

While the Windows compilers seem to be using the compilervars scripts more consistently than in the past to avoid permanent system path entries, Intel Windows MPI and other tools are cluttering the path.

Visual Studio, particularly VS2015, has contributed its own mess there.

[IanH]

I have experienced similar issues,with ifort or redistributable installations effectively breaking workstations due to system path length issues after installation of redistributables.  I am not as concerned about the path length that results from use of a compiler command prompt - as that is basically localised to activities just involving the intel tools, but playing nice with the system path is very important.  People get upset when they install my application and lots of unrelated stuff breaks.

Intel have complete control over the names that they use for their runtime support DLL's, and the number of runtime DLL's is not particularly large.  I don't understand why multiple directories are required, for the same target architecture (I'll accept different directories for different architectures), for runtime support libraries for a very related set of products.

I manually cleaned up my system path after the installation of ifort 16.0, which resulted in the following entries, which I imagine are very typical:

C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64_win\mpirt
C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32_win\mpirt
C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64_win\compiler
C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32_win\compiler

That's only about 330 characters, but it could be halved if the mpi and compiler runtime directories were merged.

There are some other redist directories still in that common files area without the _win suffix, but as far as I can tell they are for older versions that I am yet to uninstall, but given the runtimes are backwards compatible they are no longer required.

[mecej4]

Having been burned before, I routinely back up the Windows environment to a text file before installing an Intel compiler distribution. Given the absurdly inadequate sysdm.cpl control panel facilities for editing environment variables, this is still time-consuming, but manageable.

I should prefer to have the opportunity to say "no" to the installer's offer to change my system's environment, and have the installer prepare a batch file that I can run as and when desired to use the Intel compilers. I use a number of other packages and I really hate it when one package derails the others.

[jimdempseyatthecove]

I cannot understand why the design is such that the macro names are expanded prior to inserting into PATH. While not ideal, it would shorten things a bit.

$(INTEL_DEV_REDIST)intel64_win\mpirt
$(INTEL_DEV_REDIST)ia32_win\mpirt
$(INTEL_DEV_REDIST)intel64_win\compiler
$(INTEL_DEV_REDIST)ia32_win\compiler

This may not solve everything, as the PATH expansion buffer inside CMD (command shell) must be large enough to handle the expansion, but it may help. This would remove ~200 characters from the above four lines.

Jim Dempsey

[mecej4]

One annoyance related to struggling with PATH (and other environmental variables such as INCLUDE and LIB) in Windows is that many commonly used path components, such as "PROGRAM FILES", contain spaces. Often, I don't know the exact path name by heart, so I use the Windows command-completion key (TAB by default) while setting environmental variables. If the path contains a space, double quotes around the entire string become necessary, and are in fact added by command-completion -- so far, that is good. Unfortunately, quotes in PATH, LIB, etc. are poison as far as the functionality of those variables is concerned. Thus, a two-step process is required: (i) put the path together using command-completion and concatenation, and (ii) remove all quotes from the string before using it with the SET built-in command.

Any solutions to this annoying issue?

[Kevin_D_Intel]

Thank you for starting this post and I'm sorry to hear about the issue caused by the path additions. Thank you also to others for sharing your feedback. I will gather up all the feedback shared in the thread and roll it up to the Development teams for consideration of how we can improve the product in the related areas mentioned.

(Internal tracking id: TBD)

[Simon_Geard]

I had this problem with the recent beta and had to remove all the duplicates by hand.

One solution would be for the installer to write all necessary data into a file that gets parsed when the compiler shell gets started. That would enable you to avoid fiddling with system variables and would also make it easy to drive the compiler from other environments, e.g. cygwin which is currently pretty much impossible.

[TimP]

I've never had difficulty when setting cygwin paths after running compilervars (using -Qlocation,link to choose the VS linker).  It's probably outside the scope of Intel's testing program to set up a cygwin equivalent of compilervars, which would have to be based on a Microsoft vcvars for cygwin.  Microsoft doesn't even fully test how vcvars.bat works after in-place upgrades of Visual Studio.

As I mentioned above, some of the functionality has been moved from system environment to compilervars.bat, enough to permit multiple versions of compilers to coexist.  It's difficult to see why a few loose ends such as the (conflicting) versions of mpi runtime aren't dealt with the same way.  Even static linked .exe requires the environment to be set for Intel OpenMP library, so why not MPI as well?

[IanH]

When you install a version of ifort, the "common files" installation of the various runtime components is updated if the version being installed is newer than what was there previously.  I think this is appropriate - it is reasonably likely that users of the compiler may also want to run (versus develop) their application independent of a command prompt and/or Visual Studio, but perhaps some users would like that component of the installation made optional (but I suggest enabled by default).  I think requiring separate manual installation of that component unreasonable, and likely to lead to confusion on the part of users that haven't done that separate installation or, worse, workarounds such as them "manually" putting the relevant DLL's on PATH.

That "common files" set of runtimes reasonably needs to be discoverable on the system path, otherwise it kind of defeats the point of that installation, and it has more justification being on the system path than many of the other third party things that you will find there.  So I don't have an issue with the installations modifying that aspect of the system path for that installation component (when they do so, they should make sure that the addition of extra bits into path isn't going to break things without issuing some warning, and they should also be mindful about the need to remove old versions that might be in differently named directories).  But, architecture aside (and that's being generous - the DLL names could have included the architecture) why multiple directories?  You can have your multiple directories for the runtime components that are installed local to the ifort program files area if you want, because perhaps some developer needs to test obscure combinations, but that should never apply to a system global installation intended for end users. 

For other aspects of the compiler installation I would be defaulting to "don't touch any system environment variables unless the user explicitly gives me permission to" because I think most compiler users just head straight for the compiler command prompts/Visual Studio anyway.  If the length of the path that results when a compiler command prompt is started then ends being excessive, then I think it can be put back on the user to clean things up, but at least the entire system won't start misbehaving.

(mecej4 - if the presence of spaces in "Program files" is causing complications, then you could set up a alternative space free name for the directory using mklink and reference via that instead.  That sort of file system change would be available system wide, I do something similar in user space using subst)

[mecej4]

IanH, thanks, but symlinks don't work the same way. If I use the symlink name, I do not get a listing of the subdirectories within it.

s:\> dir "c:\PGMFLS"
 Volume in drive C has no label.
 Volume Serial Number is xxxx-xxxx

 Directory of c:\

10/13/2015  06:53 PM    <SYMLINK>      PGMFLS [Program Files]

Using the original name instead of the symlink, I get (showing just a few lines off the top):

s:\> dir "c:\Program Files"
 Volume in drive C has no label.
 Volume Serial Number is xxxx-xxxx

 Directory of c:\Program Files

09/09/2015  10:21 PM    <DIR>          .
09/09/2015  10:21 PM    <DIR>          ..
05/15/2015  06:16 PM    <DIR>          Application Verifier
08/03/2015  02:37 PM    <DIR>          Common Files
07/30/2015  11:53 PM    <DIR>          CONEXANT
07/30/2015  11:53 PM    <DIR>          DVD Maker
07/30/2015  11:53 PM    <DIR>          Intel
08/07/2015  11:51 AM    <DIR>          Internet Explorer

Things work better if, instead of a symlink, I use the old DOS 8.3 equivalent, PROGRA~1.

Tab completion does not work for symlinks in a command window, either. Thus, Windows symlinks just do not offer much functionality for me. Perhaps there are some registry settings that need to be changed to enable the missing functionality?

[IanH]

Hmmm.  I get different behaviour here on my Windows 7 machine - both the directory listing and completion (I map both directory and file completion to the tab) works.

Does a junction work any differently for you?

[mecej4]

IanH, I made a mistake (not knowingly) in creating the symlinks -- I did not use the /D option because I did not think it existed or was needed. If the link is created with the /D option it works correctly. That raises a question: what is the point of being able to create a symbolic link to a directory that is not a directory itself? 

[John_Campbell]

To me, the ifort install and it's associated directory structure appears to be overly complex and the cause of the problem. I think it should be rationalised, ie simplified.

There are 3 basic operating states; compiling, linking and running. The system path variable must support running, while compiling and building can be achieved via changes to a local path and additional environment variables. For compiling and building, this local path variable can be modified for this environment only, but for running, the system path must be in place. This is basically what happens at the moment, but the problem is that the organisation of files in a complex directory structure needs to be reviewed and rationalised.

I do not use VS, but I have had to install VS just to get the linker, plus what ever else is required.

Rationalise the directory structure. Make it so that if we want to switch from 32-bit to 64-bit or between different installed versions of the compiler, it is easy to achieve. ifort already requires this, but the directory complexity is over the top. I also use multiple versions of gFortran and have a simple batch file to reset the local environment variables for compile or run.

It is very easy to have multiple versions of gFortran installed; each is in it's own directory tree. My .bat file that selects a particular version provides a striped down path that supports what I need for the build process then running, while the system path supports the default version for running. ifort should do the same, which would allow support for multiple versions of the compiler. It requires a way of supporting the run time.

I think the approach is already supported with ifort, but the directory structure is just far too complex. Review what it needs to achieve and leave the other complex interactions to a local environment.

John

[oxishmit_o_]

Try Long Path Tool it helped me in those problems and it is free