<orcnote> inline -----Original Message----- From: Andre Fischer [mailto:awf....@gmail.com] Sent: Tuesday, October 21, 2014 00:38 To: dennis.hamil...@acm.org; dev@openoffice.apache.org Cc: awf....@gmail.com Subject: Re: Build System Improvements
Hi Dennis, please see my comments to your two mails inline. On 20.10.2014 19:23, Dennis E. Hamilton wrote: > Concerning refactoring the build of AOO, I wonder about Cygwin > alternatives. Msys2 may be superior with regard to being > friendly to the Windows environment: > <http://sourceforge.net/p/msys2/wiki/Contributing%20to%20MSYS2/>. As far as I know cygwin is primarily used to provide a Unix like shell environment with commands like ls, cp, sed, awk, etc. We are not using to compiling source code. So, in a sense, being Windows friendly is not the primary goal :-) But you are still making a valid point. At the moment we are forcing all platforms to use e.g. the cp command for copying files to reduce the complexity of the build scripts (and possibly because the authors could not be bothered to use the Windows platform). Using native commands might lead to shorter build times. <orcnote> Apart from the question of performance, I think the greater issue is the fact that Cygwin creates a different mapping of the "host" file system, making coordinated use of the VC++ compiler very difficult to get right. I am going to look into MSYS2 and the Lean Prover build as an easy way to do a proof of concept. I expect that I can't use the VC++ compiler in a build of the Lean Prover because of the dependencies on GMP, MPFR and Lua. I do want to know if MSYS2 provides a better approach in terms of being able to use and build native Windows programs and allow the Windows file system to correspond to POSIX file names in a more direct way. We'll see. </orcnote> > > I was led to this today when looking into this project: > <https://github.com/leanprover/lean>. That's much simpler than > building AOO. The clean instructions and the easy > handling of multiple platforms (and being good for x64 Windows) > strikes me as an excellent example. Having so little friction > in beginner AOO builds seems very desirable. Making the build easier is one of my goals but I am afraid that at the moment the initial configuration is the most complicated step. And I don't want to touch that right now. > > I'd wager that the VC++ 2013 compiler could be used more easily > There also. > > - Dennis > > Speaking of refactoring, there may be some inspiration in > this report on a benchmark Windows product being taken > multi-platform, multi-device: > <http://winsupersite.com/office/how-microsoft-taking-office-cross-platform>. > > > > -----Original Message----- > From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] > Sent: Friday, October 17, 2014 08:22 > To: dev@openoffice.apache.org > Subject: RE: Build System Improvements > > <orcnote> inline below. > > -----Original Message----- > From: Andre Fischer [mailto:awf....@gmail.com] > Sent: Friday, October 17, 2014 04:39 > To: dev@openoffice.apache.org > Subject: Re: Build System Improvements > > On 17.10.2014 13:21, Regina Henschel wrote: >> Hi Andre, >> >> will these in the long term lead to a system, where AOO can be build >> directly in MS Visual Studio without need of cygwin? > Hi Regina, > > this is not a direct goal but could become possible as a side effect. > > One of the key ideas of the proposed approach is to further separate > between dependencies and build logic and have scripts/programs transform > the dependencies into actual make files. Once the dependencies are > present as uniform XML files we can more easily write a transformation > into Visual Studio solution files. But this will still not be a > trivial task. > > It would help me if you or somebody else could provide a description or > even a specification of Visual Studio solution/project files. > > <orcnote> > I don't think you need to go all the way to solution files in order > To compile native (win32 and x64) for Windows using Visual Studio, even > Visual Studio 2013 Express for the Desktop. One can have makefile- > controlled builds and command-line compiles just fine. Well, yes. But we already have command line based builds which work quite well. The big advantage of using of environments like Visual Studio or Eclipse is that writing/editing code becomes easier. I guess that for that we need the solution files. > > Developers might want to create "makefile solution" files, but they > should not be needed in the source tree. (It might also be valuable to > understand MSBuild, which is XML-based already, and that might be a That is interesting. I was not aware of MSBuild before. I will look into it. -Andre > better alternative to constructing solution files. Finally, one reason > to make a solution file is to use VS 2013 GIT repository integration, > but that only works if pull requests become supported and cloning is > to places where pulls can reach.) > > I think an interesting aspect of Andre's proposal is that one could > Take advantage of linking and DLL creation more, not requiring full > builds so much so long as there are unchanged static libraries and > DLLs. This kind of refactoring might also be important for > configurations on limited platforms. The idea is to build and > test AOO by component layers. That might make working with > GIT more practical as well. > > (I don't mean releasing separate components, but being able to build > up dependencies in stages, even the first time as a way to start > working with a fresh clone/checkout of the source tree. Of course, > building smaller, specialized distros might be more-easily come by.) > </orcnote> > > -Andre > >> Kind regards >> Regina >> >> --------------------------------------------------------------------- >> 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 > > > --------------------------------------------------------------------- > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
