On 6/22/2015 12:02 PM, Óscar Fuentes wrote: > Edward Diener <eldlistmaili...@tropicsoft.com> > writes: > >>> Apparently those programmers are not so inconvenienced as you are by >>> having to use methods like the .bat mentioned above. And I can assure >>> you that some of those programmers have quite a few gcc installs on >>> their machines, that they use on a regular basis. >> >> You are much better than the original mingw installations but your >> reliance on having to set the PATH rather than have a direct invocation >> work correctly is a real PITA. > > As I mentioned on other message on this thread, you must set PATH > anyways for executing the resulting binaries of your compilation. There > is no possible workaround for this, other than installing libwinpthread, > libstdc++ and co. on a directory that already is on PATH. But that would > preclude having more than one MinGW(-w64) installed on your system, > among other problems.
You mention this as if it were some law of programming. Once again just because the relationships of modules ( exes and dlls ) are setup poorly in mingw-64 distros does not mean that this is the only way things could be. I have already explained that if you have all modules which need to reference each other in the same directory then some module finding another module will happen automatically in Windows. This would allow for self-enclosing distributions of mingw-64 which does NOT need the ridiculous nonsense of putting some bin directory in the PATH. You could distribute as many distros as you like and if they were all self-enclosing in the way I have mentioned you don't ever need the PATH environment variable set to any one distro's bin directory at any time. Claiming otherwise to me, who am a programmer with a pretty good understanding of how modules work under Windows, is futile unless you want to ram down my throat the information that this is the way mingw-64 does things and we are not going to change. If so I already got that message. But claiming that you can't technically do it better, just because the idiots at Microsoft are the example which you choose to follow, is utter nonsense and I am pretty sure that if you are a programmer yourself you must know that. > >>> >From what I recall, Visual Studio is even worse on this regard, as it >>> requires setting some environment variables with paths to work. That's >>> what vcvars32.bat does. How do you deal with multiple VS installs from >>> the command line? Or you just use the IDE? I'm succesfully using the >>> .bat method described above for multiple installs of VS and Mingw-w64. >> >> As my beloved mother used to say when I was a kid, "Just because your >> friend Johnny wants to jump off the top of the Empire State building >> does that mean you have to do it too?" > > That's not an answer to my question: how do you deal with multiple > installs of VS? (I'm sure you have several of them, unless you use > multiple machines, one for each) > > To recap: what you are experiencing is not a consequence of oversight or > lazyness from the MinGW(-w64) developers, but the less annoying solution > for the problem of installing one or more MinGW(-w64) instances without > causing havoc. ------------------------------------------------------------------------------ Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical & virtual servers, alerts via email & sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
