incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <dennis.hamil...@acm.org>
Subject RE: Microsoft Tools for Windows Builds
Date Sun, 20 Nov 2011 18:02:49 GMT
Hi Ross,

The goal is to be able to do the Windows Build with the free tools that Microsoft has available.
 That includes the free-to-download Microsoft Visual Studio Express software (specifically
the Visual C++ Express Edition), the Microsoft SDK, and the Windows DDK.  This assures that
anyone can do a build for Windows without having to have an MSDN Subscription or a commercially-sold
version of Visual Studio, so long as they can meet the configuration requirements for building
on a Windows PC.  

A secondary problem, independent of how one acquires the Microsoft developer tools, is that
the toolset and build structure for OO.o looks, walks, and talks like a Unix/Linux build.
 To have the build process work on Windows, cygwin (which provides a bash work-alike and a
large set of Unix-style utilities) has to have access to the Microsoft tools as if they were
installed on a Unix system that has provisions for executing Windows software.  

The experiment I did yesterday was a proof-of-concept demonstration that finding the Microsoft
tools from cygwin is easier than digging around in the Windows registry, since (1) firing
up cygwin preserves the environment variables and path that are set in Windows at the time
and (2) all of the Windows developer tool sets that run from the command-line have scripts
that setup environment variables and path for their command-line operation.  I just connected
those dots.  There is more to do to make an easily customizable bridge script, especially
for running on a localized version of Windows.  But the concept works.  It also puts the Windows-configuration
binding outside of the build itself, so it can be performed and customized prior to starting
cygwin and then initiating a build.  It's also easy to build checks into the scripts (as I
did just for locating the VC++ compiler) so that an user knows the configuration is located
properly before even attempting the build.

This may get us over some of the gnarlies that seem to be in the way of easily setting up
a Windows build.  But it is just a proof-of-concept at this point.

 - Dennis

-----Original Message-----
From: Ross Gardler [mailto:rgardler@opendirective.com] 
Sent: Sunday, November 20, 2011 02:05
To: dennis.hamilton@acm.org; ooo-dev@incubator.apache.org
Cc: Regina Henschel
Subject: Re:Microsoft Tools for Windows Builds

We used to have free MSDN licenses for Apache projects. I can't remember
the details and I'm not sure if the donation is still valid. Would this
provide what is needed in a convenient way? If so I'll find or what the
status is.

Ross

Sent from my mobile device, please forgive errors and brevity.
On Nov 20, 2011 6:07 AM, "Dennis E. Hamilton" <dennis.hamilton@acm.org>
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.
>
> Here's how I demonstrated it working.
>
>  1.  I have batch scripts that I use to launch console windows with the
> Visual
> C++ environment all set up.  One is the attached MyVC++.bat.txt (with the
> .txt
> removed).  It creates the correct path, environment variables, etc., for a
> VC++ command-line build.
>
>  2. The second batch script, VCygwin.bat.txt (without the .txt) is placed
> in
> my C:\cygwin folder where I can run it whenever I want a cygwin environment
> that is already set up to use VC++.  (A copy of MyVC++.bat is placed in the
> same folder with the original cygwin.bat script and the modified
> VCygwin.bat.)
>
>  3. What I get when the cygwin is started using VCygwin.bat is shown in the
> attached PNG file.  (In the illustrated case, I am using a MyVC++.bat that
> sets up VC++ 2010 Express Edition, what I have installed on the same
> machine I
> just added cygwin to.)
>
>  4. This same principle can be used to create a setup that uses additional
> included files and libraries of the Windows SDK and the ATL include files
> and
> libraries of the Windows DDK.  It is setup before cygwin is started and the
> settings and tools are then available for the entire session.
>
> That's how I would do it. (I need to test the same idea to see if it works
> with the bash shell in the Windows Posix SUA subsystem.)
>
> There's more too it of course because of the way the Windows file system is
> mapped for access under cygwin and how commands to the VC++ command-line
> compiler are created.  But that must be done somehow either way.
>
>  - Dennis
>
> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
> Sent: Sunday, November 06, 2011 20:49
> To: ooo-dev@incubator.apache.org
> Cc: 'Regina Henschel'
> Subject: RE: Need a current build for WinXP 32bit
>
> Thanks Mathias,
>
> I found the ATL headers in the WinDDK/.../inc/atl71/, and libraries too.
> There is also the ATL Reference Guide and other materials available at MSDN
> on-line, along with some books in a very dusty corner of my office shelves.
> That is one heck of a dependency.  I wonder how much of it actually adds to
> OO.o to do a static binding [;<).
>
> It would be interesting to see how much could be replaced by plain-vanilla
> COM
> dependencies.  Not something I will be in any hurry to dig into though.
>  Just
> something to nag my mind while I concentrate on simpler things first.
>
>  - Dennis
>
> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
> Sent: Sunday, November 06, 2011 11:44
> To: ooo-dev@incubator.apache.org
> Cc: 'Regina Henschel'
> Subject: RE: Need a current build for WinXP 32bit
>
> Thanks Mathias,
>
> I missed your earlier response.
>
> I just checked to see whether the DLLs are on my system already and they
> are
> of course.  7.1, 8.0, 9.0, and 10.0 plus related patches.
>
> I will look into the WDK.
>
> This seems a good place to start:
> <http://msdn.microsoft.com/en-us/windows/hardware/gg487463>.
> The release notes are interesting.  Hmm, 619.77 MB ISO Image.  OK, time to
> go
> do other chores while the download happens.
>
>  - Dennis
>
> -----Original Message-----
> From: Mathias Bauer [mailto:Mathias_Bauer@gmx.net]
> Sent: Thursday, November 03, 2011 01:13
> To: ooo-dev@incubator.apache.org
> Subject: Re: Need a current build for WinXP 32bit
>
> On 31.10.2011 20:18, Dennis E. Hamilton wrote:
> > Regina,
> >
> > I would like to find an already built Win32 WinXP version too.  I
> > despair of ever succeeding in building one myself without extensive
> > practice with the tools that I am expected to operate to accomplish
> > that.
> >
> > I don't know how to deal with the ATL dependencies. I thought that it
> > was going to be made available independently, but it is apparently
> > still tied to VC++ 200xy non-express editions.
>
> As I already wrote on this list some weeks ago, you can get ATL headers
> by installing the Windows driver SDK. It might require to add paths to
> your build environment, but basically it should work with VS Express.
>
> It might be an idea to install the driver SDK, get the necessary stuff,
> move it into a suitable location, adapt include path and library path of
> your build env and then deinstall the otherwise useless SDK again.
>
> Regards,
> Mathias
>


Mime
View raw message