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" <dennis.hamil...@acm.org> 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:rgard...@opendirective.com] > Sent: Sunday, November 20, 2011 02:05 > To: dennis.hamil...@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.hamil...@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.hamil...@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.hamil...@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_ba...@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 > > > >
