Reworking the MSVC-related build options

[Mat M]

Hello Tor,

Le Wed, 28 Nov 2012 20:23:09 +0100, Tor Lillqvist <tml at iki.fi> a écrit:

> Our current set of configure options related to the MSVC build
> tool-chain is quite messy and illogical. I think we should clean that
> up.
>
> Currently we have at least:
>
> --with-cl-home
> --with-mspdb-path
> --with-midl-path
> --with-csc-path
> --with-dotnet-framework-home
> --with-windows-sdk-home
> --with-directx-home
>
[...]
> Ideally, I think what we need is just one option:
>
> --with-vs=2008/2010/2012.
>
> And that option would be necessary only if you have several Visual
> Studio versions installed and want to use a non-default one. What
> should the default be then in such a case? My vote would be for the
> newest...
+1

Limiting options is a nice goal, but some will need some deep rework in  
configure. Yes, *-path and *-home are set for various reasons (not so  
logical sometimes, as you pointed out), but handling all side effects may  
be tricky, and some will be kept, I think. Also, you will need to provide  
special handling for VS express versions, since they miss some features,  
and each release a different set (Microsoft, king of tricks ;))

>
> The newest SDK installed that works with the selected Visual Studio
> should be automatically chosen.
Some nice decision tree needed here :)

> I also think we should get rid of the oowintool script. Not because it
> is Perl;) (I like Perl), but because it doesn't do anything that would
> be especially complicated to do directly in configure instead,
> Splitting similar logic into two places is always bad. And much of
> what oowintool currently does can is presumably obsolete and can be
> simplified anyway.

Yes, absolutely. I like perl, too, but oowintool is used only in configure  
and download (for testing, which could be handled by configure variables).  
It will /just/ be a new set of functions.

> Now, the problem with implementing this idea is just that testing it
> for all relevant combinations might take a lot of time... But if I try
> to make it work the best I can on my machine, and then let other
> Windows builders try other combinations... I have all three Visual
> Studios, but I am not sure if some of my SDKs are incomplete or
> broken.
I can help on this side, too.

>
> --tml

-- 
Mat M