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 OpenOffice.
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
MORE ARM-CHAIR ANALYSIS
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 all.
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
trouble-shoot.
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.
-Andre
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 [mailto:a...@a-w-f.de]
Sent: Monday, November 21, 2011 00:51
To: ooo-dev@incubator.apache.org
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.
[ ... ]
