Hi Phil, Alan,
> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Saturday, August 30, 2014 9:08 PM
>
> > 2) I tried using the nmake generator. It failed. It tried to build a
> test program to test the compiler, which failed - cl.exe reported "could not
> find
> kernel32.lib." Therefore as CMAKE was unable to find a working c compiler it
> exited.
> This is obviously ridiculous as I clearly have a working c compiler.
>
> Can't help you there, but I bet Arjen can since he routinely uses the nmake
> generator
> without such issues.
>
A missing kernel32.lib is very strange: it is one of the system libraries and
it is used in just about any program.
What happens if you compile a simpel C program manually: cl dummy.c?
> > 3) I unfortunately don't have time to start fighting with the NMake
> generator so I am returning back to the visual studio generator.
>
> Fair enough. I should tone down the negative things I said about the visual
> studio
> generators since you obviously got one of them to work.
>
> But I will say this: there are lots of such visual studio generators and at
> least one new
> one each year so CMake development resources to flush out the bugs are spread
> thin. In comparison nmake has been around forever so that generator is
> completely
> mature. Also, in your case the VS generator worked, but that may be because
> it is
> relatively mature, and when you update your VS version you will also have to
> update
> to a newer VS generator to be consistent with it. So in that case you might
> run into
> issues for a while until the genrator matures.
> Therefore, in my view it is always worthwhile to have the nmake generator
> available
> so I hope Arjen responds above to get you squared away with nmake to use as a
> reliable fallback when needed.
>
I find the variety of generators confusing myself. Especially since the version
numbers/names of the various VS's are confusing too.
>
> In the long term, the solution is for a volunteer or group of such volunteers
> to create a
> free software distribution for Windows that enforces a self-consistent set of
> packaging rules for each free software package that is included in that
> particular
> distro. Cygwin is already one such effort (in this case backed by RedHat
> rather than
> volunteers), and MinGW-w64/MSYS2 is another such distribution that has been
> put
> together quite recently by volunteers and is rapidly gaining mindshare. So
> if this and
> similar volunteer efforts continue to expand, the known current issues with
> binary
> distribution of individual packages on Windows should eventually no longer be
> of
> concern.
>
That is definitely a worthwhile goal - I know some people are awed by the
complexity of building third-party software and therefore decide against using
it. This is more important on Windows than on Linux. The "wild west" situation
Alan describes is one of the culprits.
Regards,
Arjen
DISCLAIMER: This message is intended exclusively for the addressee(s) and may
contain confidential and privileged information. If you are not the intended
recipient please notify the sender immediately and destroy this message.
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The
Netherlands, Commercial Registration Number 41146461, is not liable in any way
whatsoever for consequences and/or damages resulting from the improper,
incomplete and untimely dispatch, receipt and/or content of this e-mail.
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
