Return-Path: X-Original-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 75BCC99B2 for ; Sun, 20 Nov 2011 18:50:12 +0000 (UTC) Received: (qmail 26634 invoked by uid 500); 20 Nov 2011 18:50:12 -0000 Delivered-To: apmail-incubator-ooo-dev-archive@incubator.apache.org Received: (qmail 26585 invoked by uid 500); 20 Nov 2011 18:50:12 -0000 Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: ooo-dev@incubator.apache.org Delivered-To: mailing list ooo-dev@incubator.apache.org Received: (qmail 26577 invoked by uid 99); 20 Nov 2011 18:50:12 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 20 Nov 2011 18:50:12 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of rgardler@opendirective.com designates 74.125.82.43 as permitted sender) Received: from [74.125.82.43] (HELO mail-ww0-f43.google.com) (74.125.82.43) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 20 Nov 2011 18:50:06 +0000 Received: by wwp14 with SMTP id 14so8817234wwp.0 for ; Sun, 20 Nov 2011 10:49:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=opendirective.com; s=opendirective; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QfJ78auPurBHWyO9URL8nBrgBlj3TsMZuxexreFjknU=; b=guL0mi8rBax1+q2FEm6O/bdA+RGByYeMystCw3h7W25wiIC0Uy6r/EBkDISUvM9MaM 9r+3vLp6cfGiPFgpi234y00il6deCi/dxwIIFL7CgrbC9UD7bAN3Db/Jebm92vPhMgP2 k5srBfEsWeYCS15UMHBPfkK2VH5EzGHnZqXls= MIME-Version: 1.0 Received: by 10.180.90.148 with SMTP id bw20mr13360125wib.33.1321814985029; Sun, 20 Nov 2011 10:49:45 -0800 (PST) Received: by 10.180.106.104 with HTTP; Sun, 20 Nov 2011 10:49:45 -0800 (PST) X-Originating-IP: [86.156.135.215] Received: by 10.180.106.104 with HTTP; Sun, 20 Nov 2011 10:49:45 -0800 (PST) In-Reply-To: <008b01cca7ae$9ef02c70$dcd08550$@acm.org> References: <012401cca74a$9102f390$b308dab0$@acm.org> <008b01cca7ae$9ef02c70$dcd08550$@acm.org> Date: Sun, 20 Nov 2011 18:49:45 +0000 Message-ID: Subject: RE: Microsoft Tools for Windows Builds From: Ross Gardler To: dennis.hamilton@acm.org Cc: ooo-dev@incubator.apache.org, Regina Henschel Content-Type: multipart/alternative; boundary=f46d043be282a437ff04b22f0854 --f46d043be282a437ff04b22f0854 Content-Type: text/plain; charset=ISO-8859-1 Your goal is certainly the ideal.place to be. So no MSDN at t his time, remember it is there if you brick walls. Thanks Sent from my mobile device, please forgive errors and brevity. On Nov 20, 2011 6:02 PM, "Dennis E. Hamilton" wrote: > 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" > 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: > > . > > 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 > > > > --f46d043be282a437ff04b22f0854--