> -----Original Message----- > From: Patricia Shanahan [mailto:p...@acm.org] > Sent: Wednesday, August 31, 2016 14:20 > To: dev@openoffice.apache.org > Subject: Re: Putting Windows First ( was RE: null) > > On 8/31/2016 10:25 AM, Dennis E. Hamilton wrote: > > > > > >> -----Original Message----- From: Patricia Shanahan > >> [mailto:p...@acm.org] Sent: Wednesday, July 13, 2016 12:57 To: > >> dev@openoffice.apache.org Subject: Re: Putting Windows First ( was > >> RE: null) > >> > > [ ... ] [orcmid] > >> I would like to suggest a way of squeezing out from between the > >> rock and hard place, and getting more developers: > >> > >> Separate out the Windows build process. Pick one of the common > >> IDE's, and create a project file that sets all environment > >> variables for Windows. Get as close as possible to the step-by-step > >> build instructions for Windows being: > >> > >> Check out the source from SVN. > >> > >> Open the project file in $IDE$. > > [orcmid] > > > > I don't think it is necessary to have an IDE commitment. > > > > Everything needed to do a build on Windows can be done with > > command-line tools that are part of the Windows SDK. Other externals > > needed for builds can be obtained in Windows versions. It is how > > Visual Studio works -- it spawns command-line operations. > > To me, direct use of command line tools feels like an awkward half-way > step between the punch cards I used when I started programming, and the > IDE's I use for most of my programming now. [orcmid]
The advantage is that the command-line operation is agnostic about choice of IDE so long as one can use a chosen IDE successfully. You can also build make projects in Visual Studio. You're likely to find Git integration built in and have to do more work for SVN, but it is not a lot more work. I haven't tried Visual Code, but that might be a likely candidate too, without any of the heavyweight qualities of Visual Studio. It's integration is rather lightweight but I don't know how well it works with C++. Probably the biggest integration points (apart from source control) are line matching of compiler error messages and also build messages to a window in the IDE. I assume that anything that uses the Windows SDK and command-line compiler will handle that. I am not opposed to IDE integration, so long as it is on top of the Working check-out. When we end up making a choice of IDE in the SVN and the delivered buildable source releases, I think that won't fly. We will be forcing someone to operate with multiple tool sets and not their chosen one. Let me put it this way. We want to be able to do quality Windows builds of Windows binaries. The fall-line case is to use a freely-available native Windows toolchain. At the moment there are no IDE dependencies in the Apache OpenOffice system, and having folks be able to use IDEs is an orthogonal (but interacting) consideration. We need to enable that without imposing one, it seems to me. In any case, we are a long way from any solution to this. - Dennis > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
