Reworking the MSVC-related build options

Tor Lillqvist tml at iki.fi
Wed Nov 28 11:23:09 PST 2012


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

This is way too much, and quite misleading at least in the case of the
--with-FOO-path options: The options take the path to a program like
midl.exe, but then what configure actually does is put the *directory*
of that into PATH. And then the midl.exe command is run as such.

So in case somebody would want to (for some obscure, presumably never
happening reason) pass --with-midl-path pointing to a midl.exe in some
odd place, wanting to use just midl.exe from there, that directory
would be put in PATH, and whatever other commands that might be there
would perhaps be used, too. Rather dangerous and pointless.

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...

The newest SDK installed that works with the selected Visual Studio
should be automatically chosen.

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.

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.

--tml


More information about the LibreOffice mailing list