incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andre Fischer>
Subject Re: Microsoft Tools for Windows Builds
Date Mon, 21 Nov 2011 17:59:19 GMT
Hi Dennis,

On 21.11.2011 18:37, Dennis E. Hamilton wrote:
> Andre,
> I have my own interests in this kind of construction setup for Windows builds.  I offered
my snippets in case they are also useful in streamlining the Windows build case for Apache
> I only did a little proof of concept to confirm that the settings are conveyed into a
cygwin session properly.   There could always be a show-stopper later on.  Something I didn't
dig into was setting up the command-line parameters to the tools such that tool-understandable
paths (not cygwin ones?) are used.  I assume that already has a solution and the make processor
that is run under cygwin has no problem.
>   - Dennis
> It seemed to me that the way cygwin is used to find the necessary dependencies among
the Microsoft development tools is fragile and, seemingly, too much black art.  I based that
on observation of some folks having difficulty with getting builds to work in various cases
(at LO and here).
> It seems easier, and better for those who just want to do builds for QA,

I am not sure how a QA build differs from a developer build (other then 
in a debug flag maybe)

> to establish the tool-dependency connections before starting the build under cygwin at

configure should basically do that, making sure that everything needed 
for a build exists before starting the actual build.  If you or anybody 
else finds a better way to detect the right MS tools than we should 
adapt the automake/configure tool chain accordingly.  What we not should 
do is to have two different detection routines that may lead to 
different results.  Otherwise the first check may tell the user that 
everything is OK and then configure complains about eg a missing compiler.

 > This can be by setting up and confirming the tool-required 
environment variables and path settings first.  It is relatively easy to 
do and the Microsoft tools already have scripts that help without any 
registry dependencies required.  It should also be easier for an user to 

It would be great if the Windows tools detection could be improved.

> That way an user can choose which versions of the tools to use when many are installed
side-by-side on the same system and also know before starting a build process that the tools
are reachable.

Ah, are you talking about an interactive tool?  Which lists all sane 
combinations of tools and when the user has made her choice, configure 
is run with the selected values and prepares the build?
I would like that.


PS: I am sorry about broken formatting of quotes.  My mail application 
(Thunderbird) can not handle your long lines very well :-)

>   - Dennis
> -----Original Message-----
> From: Andre Fischer []
> Sent: Monday, November 21, 2011 00:51
> To:
> Subject: Re: Microsoft Tools for Windows Builds
> Hallo Dennis,
> I am not sure that I see the problem here (I do not read the
> libre-office mailing list but maybe I should).
> The configure script already detects which compiler to use.  This works
> well on my Windows machine with cygwin and VC++ and the MS SDKs.  The
> only problem I have encountered so far is when several versions of
> visual studio or the SDKs (old and new, 32bit and 64bit) are installed
> at the same time and configure has to make a choice.  But this is may
> not be auto-detectable by any means.  For this we have options with
> which to tell configure which version to use.
> But maybe I misunderstand the problem entirely?
> Best regards,
> Andre
> On 20.11.2011 07:06, Dennis E. Hamilton wrote:
>> Another conversation came up (on [libre-office]) on how to find the installed
>> VC++ software from within cygwin.  The attempted approach involved
>> mucking-about in the Windows Registry in order to track down the tools.  That
>> struck me as the long way around.  The Windows Developer Tools themselves are
>> able to bootstrap command-line environments using a few environment variables
>> and some batch scripts as levers.
>> I also confirmed that when cygwin starts up, it absorbs the path and
>> environment variables that exist at the time.
>> This preconditioning seems much healthier than attempting to reach out from
>> cygwin into the Windows environment.
> [ ... ]

View raw message