You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Andre Fischer <aw...@gmail.com> on 2014/10/17 09:32:34 UTC
Build System Improvements
As you may know, in the past years I have made a couple of experiments
regarding the
build system of AOO. With the resulting experience I
would now like to start to work on improving the build system. I have
in mind a
"soft conversion" that gradually replaces parts of the existing build
system, not a big push that takes years to complete and then breaks
everything.
I would like to start with some under-the-hood changes to how the
build process is controlled. At the moment we have prj/build.lst
files that control how build.pl builds the dmake modules. Then there
are makefiles.mk in directories of dmake modules and finally we have
makefiles in gbuild modules. All of them are not makefiles in the
classical sense, i.e. they seldomly contain directives of how to build
a target. They are data files that primarily define dependencies
between targets or, for example, which object files go into a shared
library. They use three different, mostly unspecified and
undocumented, notations.
The first work item would be the conversion of these files into a
unified XML syntax. At first these XML files would be converted back
to the old syntax on-demand and on-the-fly so that the old build tool
chain can still be used. Subsequent steps would then improve or replace
parts of this tool chain.
If you don't object to this general plan then I would start the XML
conversion with the prj/build.lst files as proof of concept. I would
also start to write Wiki pages that explain in more detail how the
current build process works, what its draw backs are, and how, in my
opinion, it can be improved.
Best regards,
Andre
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Build System Improvements
Posted by Andre Fischer <aw...@gmail.com>.
Am 17.10.2014 19:33, schrieb Kay Schenk:
> On Fri, Oct 17, 2014 at 12:32 AM, Andre Fischer <aw...@gmail.com> wrote:
>
>> As you may know, in the past years I have made a couple of experiments
>> regarding the
>> build system of AOO. With the resulting experience I
>> would now like to start to work on improving the build system. I have in
>> mind a
>> "soft conversion" that gradually replaces parts of the existing build
>> system, not a big push that takes years to complete and then breaks
>> everything.
>>
>> I would like to start with some under-the-hood changes to how the
>> build process is controlled. At the moment we have prj/build.lst
>> files that control how build.pl builds the dmake modules. Then there
>> are makefiles.mk in directories of dmake modules and finally we have
>> makefiles in gbuild modules. All of them are not makefiles in the
>> classical sense, i.e. they seldomly contain directives of how to build
>> a target. They are data files that primarily define dependencies
>> between targets or, for example, which object files go into a shared
>> library. They use three different, mostly unspecified and
>> undocumented, notations.
>>
>> The first work item would be the conversion of these files into a
>> unified XML syntax. At first these XML files would be converted back
>> to the old syntax on-demand and on-the-fly so that the old build tool
>> chain can still be used.
>
> Q: Could a build change like this just be used for SOME modules without
> having to convert back?
The conversion back to the existing build.lst, dmake or gbuild files is
just a migration step. The goal is to replace
all these with a unified build system. But that second step is much
harder than the first.
>
>> Subsequent steps would then improve or replace
>> parts of this tool chain.
>>
>> If you don't object to this general plan then I would start the XML
>> conversion with the prj/build.lst files as proof of concept. I would
>> also start to write Wiki pages that explain in more detail how the
>> current build process works, what its draw backs are, and how, in my
>> opinion, it can be improved.
>>
>> Best regards,
>> Andre
>>
>>
>>
> This sounds interesting and I can't wait to see what happens next!
>
> Is this Ant-like? Or can be used by Ant...which we use already for some
> things?
The format will borrow some ideas from ant but should be a lot simpler.
It is intended to be read by transformation scripts and I certainly
don't want to write an parser for Ant files :-)
-Andre
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Build System Improvements
Posted by Kay Schenk <ka...@gmail.com>.
On Fri, Oct 17, 2014 at 12:32 AM, Andre Fischer <aw...@gmail.com> wrote:
> As you may know, in the past years I have made a couple of experiments
> regarding the
> build system of AOO. With the resulting experience I
> would now like to start to work on improving the build system. I have in
> mind a
> "soft conversion" that gradually replaces parts of the existing build
> system, not a big push that takes years to complete and then breaks
> everything.
>
> I would like to start with some under-the-hood changes to how the
> build process is controlled. At the moment we have prj/build.lst
> files that control how build.pl builds the dmake modules. Then there
> are makefiles.mk in directories of dmake modules and finally we have
> makefiles in gbuild modules. All of them are not makefiles in the
> classical sense, i.e. they seldomly contain directives of how to build
> a target. They are data files that primarily define dependencies
> between targets or, for example, which object files go into a shared
> library. They use three different, mostly unspecified and
> undocumented, notations.
>
> The first work item would be the conversion of these files into a
> unified XML syntax. At first these XML files would be converted back
> to the old syntax on-demand and on-the-fly so that the old build tool
> chain can still be used.
Q: Could a build change like this just be used for SOME modules without
having to convert back?
> Subsequent steps would then improve or replace
> parts of this tool chain.
>
> If you don't object to this general plan then I would start the XML
> conversion with the prj/build.lst files as proof of concept. I would
> also start to write Wiki pages that explain in more detail how the
> current build process works, what its draw backs are, and how, in my
> opinion, it can be improved.
>
> Best regards,
> Andre
>
>
>
This sounds interesting and I can't wait to see what happens next!
Is this Ant-like? Or can be used by Ant...which we use already for some
things?
--
-------------------------------------------------------------------------------------------------
MzK
"Success breeds complacency. Complacency breeds failure.
Only the paranoid survive."
-- Andy Grove, Intel Co-founder
Re: Build System Improvements
Posted by Andre Fischer <aw...@gmail.com>.
Am 18.10.2014 11:56, schrieb Andrea Pescetti:
> On 17/10/2014 Andre Fischer wrote:
>> improving the build system. I have in mind a
>> "soft conversion" that gradually replaces parts of the existing build
>> system, not a big push that takes years to complete and then breaks
>> everything.
>
> This seems a reasonable approach. But this is the n-th time that
> someone proposes a new build system.
I am aware of that and understand that you are sceptical. For that very
reason I propose a first step that just introduces a different notation
for our makefiles without (big) changes to the underlying build system.
The next step of actually replacing parts of the build system with
something better is certainly much harder and less likely to succeed.
> Can I ask at least if there is anything (in terms of knowledge, if not
> of code) that came out of
> https://wiki.openoffice.org/wiki/Build_System_Analysis:capstone2013_windows_build
> that can be reused here?
>
> The aim of that project was not reached, but still the analysis and
> discussion might be worth reviewing (probably you already did). And
> maybe there is some knowledge from that project that hasn't been
> documented yet.
>
>> If you don't object to this general plan then I would start the XML
>> conversion with the prj/build.lst files as proof of concept. I would
>> also start to write Wiki pages that explain in more detail how the
>> current build process works, what its draw backs are, and how, in my
>> opinion, it can be improved.
>
> This is very good; had it come one month ago, we could have submitted
> it as a Capstone project for 2014 so that you would get a small team
> of students to mentor for a few months. But there might be other
> opportunities if you believe that new developers can work on this task
> without an excessive strain on you as a mentor.
I do. But I need a week or two to set this all up.
Regards,
Andre
>
> Regards,
> Andrea.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Build System Improvements
Posted by Andrea Pescetti <pe...@apache.org>.
On 17/10/2014 Andre Fischer wrote:
> improving the build system. I have in mind a
> "soft conversion" that gradually replaces parts of the existing build
> system, not a big push that takes years to complete and then breaks
> everything.
This seems a reasonable approach. But this is the n-th time that someone
proposes a new build system. Can I ask at least if there is anything (in
terms of knowledge, if not of code) that came out of
https://wiki.openoffice.org/wiki/Build_System_Analysis:capstone2013_windows_build
that can be reused here?
The aim of that project was not reached, but still the analysis and
discussion might be worth reviewing (probably you already did). And
maybe there is some knowledge from that project that hasn't been
documented yet.
> If you don't object to this general plan then I would start the XML
> conversion with the prj/build.lst files as proof of concept. I would
> also start to write Wiki pages that explain in more detail how the
> current build process works, what its draw backs are, and how, in my
> opinion, it can be improved.
This is very good; had it come one month ago, we could have submitted it
as a Capstone project for 2014 so that you would get a small team of
students to mentor for a few months. But there might be other
opportunities if you believe that new developers can work on this task
without an excessive strain on you as a mentor.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Build System Improvements
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 17/10/14 09:32, Andre Fischer wrote:
> As you may know, in the past years I have made a couple of experiments
> regarding the
> build system of AOO. With the resulting experience I
> would now like to start to work on improving the build system. I have
> in mind a
> "soft conversion" that gradually replaces parts of the existing build
> system, not a big push that takes years to complete and then breaks
> everything.
>
> I would like to start with some under-the-hood changes to how the
> build process is controlled. At the moment we have prj/build.lst
> files that control how build.pl builds the dmake modules. Then there
> are makefiles.mk in directories of dmake modules and finally we have
> makefiles in gbuild modules. All of them are not makefiles in the
> classical sense, i.e. they seldomly contain directives of how to build
> a target. They are data files that primarily define dependencies
> between targets or, for example, which object files go into a shared
> library. They use three different, mostly unspecified and
> undocumented, notations.
>
> The first work item would be the conversion of these files into a
> unified XML syntax. At first these XML files would be converted back
> to the old syntax on-demand and on-the-fly so that the old build tool
> chain can still be used. Subsequent steps would then improve or replace
> parts of this tool chain.
>
> If you don't object to this general plan then I would start the XML
> conversion with the prj/build.lst files as proof of concept. I would
> also start to write Wiki pages that explain in more detail how the
> current build process works, what its draw backs are, and how, in my
> opinion, it can be improved.
>
everything that help us with the build system is welcome and hopefully
we can drop the crap of the gbuild stuff instead of completing it.
Juergen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: Build System Improvements
Posted by "Dennis E. Hamilton" <de...@acm.org>.
<orcnote> inline
-----Original Message-----
From: Andre Fischer [mailto:awf.aoo@gmail.com]
Sent: Tuesday, October 21, 2014 00:38
To: dennis.hamilton@acm.org; dev@openoffice.apache.org
Cc: awf.aoo@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.hamilton@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.aoo@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-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Build System Improvements
Posted by Andre Fischer <aw...@gmail.com>.
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.
>
> 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.hamilton@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.aoo@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-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: Build System Improvements
Posted by "Dennis E. Hamilton" <de...@acm.org>.
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/>.
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.
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.hamilton@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.aoo@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.
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
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-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: Build System Improvements
Posted by "Dennis E. Hamilton" <de...@acm.org>.
<orcnote> inline below.
-----Original Message-----
From: Andre Fischer [mailto:awf.aoo@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.
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
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-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Build System Improvements
Posted by Andre Fischer <aw...@gmail.com>.
Am 17.10.2014 20:50, schrieb Greg Bullock:
>
> On 10/17/2014 4:38 AM, Andre Fischer wrote:
>> 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.
>>
>> -Andre
>
> Hi Andre.
>
> With other projects, I've had generally good success using CMake,
> which can generate Visual Studio solution/project files of various VS
> versions (as well as makefiles and other types of "project" files).
>
> Even if the team prefers not to standardize on CMake for the entire
> build process (although, that may be a worthy option), the
> dependencies and build logic from the XML files could be used to
> generate a set of CMakeList.txt files, and with those at hand, CMake
> can then take over and generate the Visual Studio solution/project files.
Hi Greg,
as you already hinted at, I intend the XML files to be an intermediate
file format. Easy to read so that we can write translations into actual
build systems like CMake.
-Andre
>
> Regards.
> Greg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Build System Improvements
Posted by Greg Bullock <gr...@nwra.com>.
On 10/17/2014 4:38 AM, Andre Fischer wrote:
> 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.
>
> -Andre
Hi Andre.
With other projects, I've had generally good success using CMake, which
can generate Visual Studio solution/project files of various VS
versions (as well as makefiles and other types of "project" files).
Even if the team prefers not to standardize on CMake for the entire
build process (although, that may be a worthy option), the dependencies
and build logic from the XML files could be used to generate a set of
CMakeList.txt files, and with those at hand, CMake can then take over
and generate the Visual Studio solution/project files.
Regards.
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Build System Improvements
Posted by Andre Fischer <aw...@gmail.com>.
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.
-Andre
>
> Kind regards
> Regina
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Build System Improvements
Posted by Regina Henschel <rb...@t-online.de>.
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?
Kind regards
Regina
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org