On Wednesday, 16 October 2013 at 02:45:26 UTC, Manu wrote:
I just tried your '-3' version. It has problems.
[snip]
2: gcstub64.obj and phobos64.lib are still in
D/dmd2/windows/lib. They
should be moved to lib64/
3: sc.ini contains: LIB="%@P%\..\lib64";"%@P%\..\lib" <- why
is '../lib/'
still present in [Environment64]? That should be removed, it
can only lead
to erroneous attempts to link the OMF libs. Rather have a
"can't find lib"
error, than a weird lib format error that most programmers
won't understand.
I agree. It's just a matter of getting Walter on board. He
hasn't said yay or nay to lib64 but he's just put sc.ini in the
repo now for hot steamy pull request action so I think he's
probably down.
4: It fails to find the Microsoft libs. Here is the relevant
parts of my
sc.ini as installed by the installer:
LIB="%@P%\..\lib64";"%@P%\..\lib"
;;;; search path for C Runtime libraries
; the following lib path works with VS2008, VS2010, VS2012,
VS2013
; prepending because 32-bit OMF versions can cause link.exe to
fail
LIB="C:\Program Files (x86)\Microsoft Visual Studio
11.0\VC\lib\amd64";%LIB%
;;;; search path for Platform libraries
; the following lib path works with Windows SDK 6.x and 7.x
LIB="C:\Program Files (x86)\Windows
Kits\8.0\lib\winv6.3\um\x64";%LIB%
; the following lib path works with Windows SDK 8.0 and 8.1
LIB="%WindowsSdkDir%Lib\win8\um\x64";%LIB%
I have VS2010 and VS2012 installed on a Win8 machine. I have
libs in these
locations:
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\x64 <-
this one
seems to be unknown to the installer. These libs should be used
in
conjunction with VS2010.
C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\x64 <- the
installer
refers to %WindowsSdkDir%, which is not present on my system.
Use the
absolute path instead? These libs are to use used in
conjunction with
VS2012.
C:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\lib\amd64 <-
runtime libs, how to pick which version? Prompt during
installation?
C:\Program Files (x86)\Microsoft Visual Studio
11.0\VC\lib\amd64 <-
runtime libs, how to pick which version? Prompt during
installation?
I should note that I think VisualD needs to do some work here
too. VisualD
should override the linker and lib paths, since it has more
information.
Ie, how does cmdline DMD choose which linker/runtime libs to
use? Perhaps a
prompt during installation? Choose the newest (appears to be
the current
behaviour).
Whereas VisualD will be running inside of an instance of either
VS2010 or
VS2012 (I use both, this is very common practise) on my
machine, and it
should configure the linker and lib paths appropriately for the
version of
VisualStudio currently in use when building, otherwise there
will be link
troubles against C/C++ libraries also being built in the same
solution
(yes, it's common to have C/C++ and D in the same solution).
For clarity, on my system, when using the VS2010 compiler, it
should use
these lib paths:
runtime libs: C:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\lib\amd64
windows libs: C:\Program Files (x86)\Microsoft
SDKs\Windows\v7.0A\Lib\x64
<- AFAIK, Microsoft SDKs is the old location, installed with
VS2010 and
earlier.
When using the VS2012 compiler, it should use these paths:
runtime libs: C:\Program Files (x86)\Microsoft Visual Studio
11.0\VC\lib\amd64
windows libs: C:\Program Files (x86)\Windows
Kits\8.0\Lib\win8\um\x64
<- Windows Kits is the new location, by versions > VS2010
(AFAIK).
The default installation of DMD using your new installer fails
to link on
my machine because %WindowsSdkDir% is not defined on my system,
and since
the 32bit dmd lib path is still present, it tries to link the
OMF libs, and
complains a lot.
Very odd that it replaced one instance of %WindowsSdkDir% but not
the last one (the installer does a find and replace on some of
the environment variables with the paths it has detected from the
registry). It probably has to do with the lack of newline on that
final line in the file. I'll fix that before this next attempt.
Elsewhere in the file, you detect VS2010LINKCMD, VS2013LINKCMD,
etc. Why
not also have a matching suite of VS2010LIBPATH="C:\Program
Files
(x86)\Microsoft Visual Studio 10.0\VC\lib\amd64" and friends,
and refer to
them down the bottom as LIB=%VS2010LIBPATH%;%LIB%, along
with LINKCMD64=%VS2010LINKCMD%.
Ie, detect versions of VS present, produce a VS20##LINKCMD and
VS20##LIBPATH appropriately for each version in their little
section, then
at the bottom, assign the actual variables used by DMD to the
version
selected by the user when prompted during installation. The
result of this
is that sc.ini will be very easy to read and understand, and if
the user
later wants to switch to another VS version, it'll be obvious
to change the
reference to the VS20## variables.
I'm switching to a simpler approach for this next iteration which
I will post shortly.
My primary VS environment is VS2010, which is going to be wrong
if the
installer uses a 'prefer newest version' strategy.
I'll see what I can do but I may run out of time to get this in
for 2.064. I think prefer newest is probably a good default but
I'm open to hearing why that might not be the case.
Another question, why use LINKCMD64? Shouldn't it just be
LINKCMD, since
it's under the [Environment64] block? You're not using LIB64,
or any others
like that.
I think others mentioned this but this has already been fixed.
