You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Peter Kovacs <pe...@apache.org> on 2017/09/05 14:11:39 UTC
[Discussion] build tool
Hello all,
To be honest I am not very happy with gmake and ant. It is difficult to
add the functionality to Eclipse. Also we stay dependant for Windows on
Cygwin or Windows Subsystem for Linux, which feels to me awkward. Also
if we want to have people develop on Windows. A good build environment
is vital.
I think I have found a better replacement that supports our needs.
Plus is IMHO realy visionary in how to develop a C++ Project.
Maven with the Nar-maven-plugin
Maven can
# Manage our dependencies
# compile Java
# Compile C++
# Compile JNI interfaces (I am not sure dont we use this massivly)
# The setup works for Windows, Linux, MacOS, Solaris, ... (BSD? have to
evaluate)
It will give us
# Integration in Eclipse
# Internal Versioning on our own Moduls. (Resulting in an easier
Release Process)
# Target OS specific build recepies can be maintained.
# prepackaged Java dependencies (I hope, havent checked)
It has potential to supply
# a direct and complete Windows build environment. (I am not sure if we
need cygwin for providing our C++ dependencies, or what possibilities
we have)
There are some caveeats to this Approach
# Apache Maven has not included the nar-maven-plugin
Do not know the consequences. Maybe I think to much. Just want it to be
transparent.
# Plugin status
Nar-maven-plugin is advocated as mature, but development team is
voluntary base as we are. Only handfull of projects use this approach.
I think they have like 3 active people.
# Features
I think we maven will give us only the ability to compile and tests. No
packaging and signing as of now. At least have not seen any ressources.
# Need of own C++ Repository
We have to build our own Nar Maven repository for our dependencies. I
have read it is a streight forward process. But still, work.
# Project structure
IMHO the biggest one. We must restructure the Project in order to
utilize the build tool. The requirement is
/yourproject
/src
/main
/java
/resources
/include
/c++
/c
/fortran
/test
/java
/resources
/include
/c++
/c
/fortran
Moduls are supported through maven. So we can do something like:
/Openoffice
/sw
/main
/java
/ressources
/include
/c++
/c
/fortran
/test
/java
/resources
/include
/c++
/c
/fortran
Ressources to read for more info:
Apache maven - https://maven.apache.org/index.html
Nar-maven-plugin - http://maven-nar.github.io/#
Eclipse Connector for the plugin - https://github.com/maven-nar/m2e-nar
What are your thoughts? - Have not found any Discussion in the archive
in this direction before.
If okay I would like to evaluate on the feasability. If I talk to
people I will just say that I am evaluating. No desicion has been taken
or requested.
It is because I think If I start talking it is quite opvious where I
come from. Dont do that many Public projects ;) Especially on Github.
(I also invite you to have a look ;) )
All the best
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [Discussion] build tool
Posted by Peter Kovacs <pe...@apache.org>.
Am Dienstag, den 05.09.2017, 07:16 -0700 schrieb Patricia Shanahan:
> On 9/5/2017 7:11 AM, Peter Kovacs wrote:
> > Hello all,
> >
> > To be honest I am not very happy with gmake and ant. It is
> > difficult to
> > add the functionality to Eclipse. Also we stay dependant for
> > Windows on
> > Cygwin or Windows Subsystem for Linux, which feels to me awkward.
> > Also
> > if we want to have people develop on Windows. A good build
> > environment
> > is vital.
>
> I am curious about why you consider the requirement for Cygwin to be
> awkward.
>
> I use UNIX command line tools, especially the svn command and the
> combination of find and grep, far too often to not have Cygwin
> running
> anyway.
>
Cygwin brings much more then commandline tools. It is a complete System
on a system. It has a complete brainwashed Interface for maintaining
your installation. It is not very well integrated to the Windows
Platform, which I very much dislike.
I think you have to respect the Platform you provide the service for.
However I dont like Putty either. So I am a very special case of a
nerd. There are good alternatives around, thought.
I like MobaXterm. Has all I want ready to use. Including ready to use
XServer support for SSH. There is a USB version out there that does not
need any installation. The xserver support was a bit awkward on cygwin
when I tried to set it up. (that was years ago.)
It is a broken down Cygwin, but much better integrated and usability.
Or I like git for Windows which provides a bash.
There is also a Bash for Windows project I think. In combination with
ConEmu it is realy good. If you jsut need a small bash.
I think there is also a bash for Windows project.
And I think Powershell is a good alternative to bash. I enjoy using it
even I have to learn the different approach it takes. But logic is
pretty streight forward. On my work Laptop I use ConEmu with it.
And I am a big fan of chocolatey. At least as much as a Windows
disliker like me can be a fan of something on Windows ;)
Plus in my experience Windows Users (Developer or not) tend to react
quite allergic to Linux and other half eaten fruit OSes. So not haveing
them to install that, is a lower barrier. :)
In general all People I met reacted quite allergic to the system they
were not a fanboy of.
All the best
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [Discussion] build tool
Posted by Patricia Shanahan <pa...@acm.org>.
On 9/5/2017 7:11 AM, Peter Kovacs wrote:
> Hello all,
>
> To be honest I am not very happy with gmake and ant. It is difficult to
> add the functionality to Eclipse. Also we stay dependant for Windows on
> Cygwin or Windows Subsystem for Linux, which feels to me awkward. Also
> if we want to have people develop on Windows. A good build environment
> is vital.
I am curious about why you consider the requirement for Cygwin to be
awkward.
I use UNIX command line tools, especially the svn command and the
combination of find and grep, far too often to not have Cygwin running
anyway.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [Discussion] build tool
Posted by Marcus <ma...@wtnet.de>.
Am 06.09.2017 um 12:46 schrieb Peter Kovacs:
> Am Dienstag, den 05.09.2017, 20:18 +0200 schrieb Peter Kovacs:
>> Am Dienstag, den 05.09.2017, 17:59 +0200 schrieb Damjan Jovanovic:
>>> On Tue, Sep 5, 2017 at 4:11 PM, Peter Kovacs <pe...@apache.org>
>>> wrote:
>>>
>>>> Hello all,
>>>>
>>>> To be honest I am not very happy with gmake and ant. It is
>>>> difficult to
>>>> add the functionality to Eclipse. Also we stay dependant for
>>>> Windows on
>>>> Cygwin or Windows Subsystem for Linux, which feels to me awkward.
>>>> Also
>>>> if we want to have people develop on Windows. A good build
>>>> environment
>>>> is vital.
>>>>
>>>
>>> What do you mean by "add the functionality to Eclipse"?
>>>
>>> On Windows, I don't think our (new) Ant projects need Cygwin or
>>> Windows
>>> System for Linux to open in Eclipse after AOO is built. Do they?
>>
>>
> Update:
> Eclipse to day seems not to be able to parse configuration or make
> files. They generate the buildtool relevant stuff from their own
> metadata.
> So I have to setup all the Information from source in Eclipse manually
> in order to get a decend Error Parser and IDE support.
>
> Since maven is a known beast to Eclipse I think that Parsing POMs
> should be a part of the toolset already. So I think in term of getting
> the Build Configuration right, the step should be covored from the POM
> file.
>
> So in the end it seems in order to get a decend Eclipse IDE support we
> need
> a) makefile parser that can handle our customs
> b) teach maven to handle our custom stuff.
>
> My hope is that option b) is cheaper in development effort.
>
> I hope that makes it more clear. In case anyone wonders, I learn as I
> go. So this is my updated understanding from yesterday. And it is very
> difficult to put in words what my guts tell me. I often do not know
> where to look or what the relevant Information is.
> I am sorry that I have expressed myself in incompetent means, and I
> dislike it a lot. However if I do not talk with the competence I have,
> it takes ages for me to provide to the community something. means I am
> even slower then I am today.
> So I hope for your continued patience and support and guidance :).
the build system is a beast with a lot shoals and bitchiness. Nowadays I
think nobody is here who knows everything. We all express our experience
so far. And you are (a new) one of us.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [Discussion] build tool
Posted by Peter Kovacs <pe...@apache.org>.
Am Dienstag, den 05.09.2017, 20:18 +0200 schrieb Peter Kovacs:
> Am Dienstag, den 05.09.2017, 17:59 +0200 schrieb Damjan Jovanovic:
> > On Tue, Sep 5, 2017 at 4:11 PM, Peter Kovacs <pe...@apache.org>
> > wrote:
> >
> > > Hello all,
> > >
> > > To be honest I am not very happy with gmake and ant. It is
> > > difficult to
> > > add the functionality to Eclipse. Also we stay dependant for
> > > Windows on
> > > Cygwin or Windows Subsystem for Linux, which feels to me awkward.
> > > Also
> > > if we want to have people develop on Windows. A good build
> > > environment
> > > is vital.
> > >
> >
> > What do you mean by "add the functionality to Eclipse"?
> >
> > On Windows, I don't think our (new) Ant projects need Cygwin or
> > Windows
> > System for Linux to open in Eclipse after AOO is built. Do they?
>
>
Update:
Eclipse to day seems not to be able to parse configuration or make
files. They generate the buildtool relevant stuff from their own
metadata.
So I have to setup all the Information from source in Eclipse manually
in order to get a decend Error Parser and IDE support.
Since maven is a known beast to Eclipse I think that Parsing POMs
should be a part of the toolset already. So I think in term of getting
the Build Configuration right, the step should be covored from the POM
file.
So in the end it seems in order to get a decend Eclipse IDE support we
need
a) makefile parser that can handle our customs
b) teach maven to handle our custom stuff.
My hope is that option b) is cheaper in development effort.
I hope that makes it more clear. In case anyone wonders, I learn as I
go. So this is my updated understanding from yesterday. And it is very
difficult to put in words what my guts tell me. I often do not know
where to look or what the relevant Information is.
I am sorry that I have expressed myself in incompetent means, and I
dislike it a lot. However if I do not talk with the competence I have,
it takes ages for me to provide to the community something. means I am
even slower then I am today.
So I hope for your continued patience and support and guidance :).
Thank you!
All the Best
Peter
> ---------------------------------------------------------------------
> 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: [Discussion] build tool
Posted by Peter Kovacs <le...@posteo.de>.
Am Dienstag, den 05.09.2017, 17:59 +0200 schrieb Damjan Jovanovic:
> On Tue, Sep 5, 2017 at 4:11 PM, Peter Kovacs <pe...@apache.org>
> wrote:
>
> > Hello all,
> >
> > To be honest I am not very happy with gmake and ant. It is
> > difficult to
> > add the functionality to Eclipse. Also we stay dependant for
> > Windows on
> > Cygwin or Windows Subsystem for Linux, which feels to me awkward.
> > Also
> > if we want to have people develop on Windows. A good build
> > environment
> > is vital.
> >
>
> What do you mean by "add the functionality to Eclipse"?
>
> On Windows, I don't think our (new) Ant projects need Cygwin or
> Windows
> System for Linux to open in Eclipse after AOO is built. Do they?
If I want to be able to build inside the IDE I need to teach the IDE
what to do. If the Eclipse just could support Open Office out from the
box all Development task will be easier to do. And even our small team
of volunteers could do the maintenance, even implement features.
*sight* What a Challenge this Pile of Code is!
>
>
> >
> > Ressources to read for more info:
> > Apache maven - https://maven.apache.org/index.html
> > Nar-maven-plugin - http://maven-nar.github.io/#
> > Eclipse Connector for the plugin - https://github.com/maven-nar/m2e
> > -nar
> >
> > What are your thoughts? - Have not found any Discussion in the
> > archive
> > in this direction before.
> >
> >
>
> In their presentation, "Unsupported" (page 29) includes showstoppers
> like
> "binaries" and "linking with shared libraries" (!!), making it
> completely
> unusable to 99% of our modules without major changes.
>
Thanks for pointing out. I have a check. Linking with shared Libraries
is kind of essential in total. I mean not only for us.
> There's also no Objective C.
Yes I saw. CDT is sadly also not suporting Objectif-C. The hole
complexity stays a challenge.
There are some words that the plugin supports the native Compilers.
I thought maybe that this is not so difficult to add on the building
site.
>
>
>
> > If okay I would like to evaluate on the feasability. If I talk to
> > people I will just say that I am evaluating. No desicion has been
> > taken
> > or requested.
> > It is because I think If I start talking it is quite opvious where
> > I
> > come from. Dont do that many Public projects ;) Especially on
> > Github.
> > (I also invite you to have a look ;) )
> >
>
> If you do, please have a look at main/solenv/inc and
> main/solenv/gbuild for
> what's involved as well. It's easy to overlook the vastness and
> complexity
> of our existing build systems, after all we have custom toolchains
> doing
> custom localization, custom configuration, custom testing, custom
> "javadoc"-like documentation, custom everything. Porting *those* to
> something else is **hard**, and even the gbuild migration didn't try
> to do
> that. Also those custom makefiles/tools/scripts needs awk, Perl,
> grep, sed,
> zip, and other *nix utilities themselves, hence also the need for
> Cygwin...
Thanks, also a good hint. *Phew* Well seems like everything beyond
pure bugfixing is hard work.
> Damjan
All the best
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [Discussion] build tool
Posted by Damjan Jovanovic <da...@apache.org>.
On Tue, Sep 5, 2017 at 4:11 PM, Peter Kovacs <pe...@apache.org> wrote:
> Hello all,
>
> To be honest I am not very happy with gmake and ant. It is difficult to
> add the functionality to Eclipse. Also we stay dependant for Windows on
> Cygwin or Windows Subsystem for Linux, which feels to me awkward. Also
> if we want to have people develop on Windows. A good build environment
> is vital.
>
What do you mean by "add the functionality to Eclipse"?
On Windows, I don't think our (new) Ant projects need Cygwin or Windows
System for Linux to open in Eclipse after AOO is built. Do they?
>
> I think I have found a better replacement that supports our needs.
> Plus is IMHO realy visionary in how to develop a C++ Project.
>
> Maven with the Nar-maven-plugin
>
> Maven can
> # Manage our dependencies
> # compile Java
> # Compile C++
> # Compile JNI interfaces (I am not sure dont we use this massivly)
> # The setup works for Windows, Linux, MacOS, Solaris, ... (BSD? have to
> evaluate)
>
> It will give us
> # Integration in Eclipse
> # Internal Versioning on our own Moduls. (Resulting in an easier
> Release Process)
> # Target OS specific build recepies can be maintained.
> # prepackaged Java dependencies (I hope, havent checked)
>
> It has potential to supply
> # a direct and complete Windows build environment. (I am not sure if we
> need cygwin for providing our C++ dependencies, or what possibilities
> we have)
>
> There are some caveeats to this Approach
> # Apache Maven has not included the nar-maven-plugin
> Do not know the consequences. Maybe I think to much. Just want it to be
> transparent.
> # Plugin status
> Nar-maven-plugin is advocated as mature, but development team is
> voluntary base as we are. Only handfull of projects use this approach.
> I think they have like 3 active people.
> # Features
> I think we maven will give us only the ability to compile and tests. No
> packaging and signing as of now. At least have not seen any ressources.
> # Need of own C++ Repository
> We have to build our own Nar Maven repository for our dependencies. I
> have read it is a streight forward process. But still, work.
> # Project structure
> IMHO the biggest one. We must restructure the Project in order to
> utilize the build tool. The requirement is
> /yourproject
> /src
> /main
> /java
> /resources
> /include
> /c++
> /c
> /fortran
> /test
> /java
> /resources
> /include
> /c++
> /c
> /fortran
>
> Moduls are supported through maven. So we can do something like:
> /Openoffice
> /sw
> /main
> /java
> /ressources
> /include
> /c++
> /c
> /fortran
> /test
> /java
> /resources
> /include
> /c++
> /c
> /fortran
>
>
> Ressources to read for more info:
> Apache maven - https://maven.apache.org/index.html
> Nar-maven-plugin - http://maven-nar.github.io/#
> Eclipse Connector for the plugin - https://github.com/maven-nar/m2e-nar
>
> What are your thoughts? - Have not found any Discussion in the archive
> in this direction before.
>
>
In their presentation, "Unsupported" (page 29) includes showstoppers like
"binaries" and "linking with shared libraries" (!!), making it completely
unusable to 99% of our modules without major changes.
There's also no Objective C.
> If okay I would like to evaluate on the feasability. If I talk to
> people I will just say that I am evaluating. No desicion has been taken
> or requested.
> It is because I think If I start talking it is quite opvious where I
> come from. Dont do that many Public projects ;) Especially on Github.
> (I also invite you to have a look ;) )
>
If you do, please have a look at main/solenv/inc and main/solenv/gbuild for
what's involved as well. It's easy to overlook the vastness and complexity
of our existing build systems, after all we have custom toolchains doing
custom localization, custom configuration, custom testing, custom
"javadoc"-like documentation, custom everything. Porting *those* to
something else is **hard**, and even the gbuild migration didn't try to do
that. Also those custom makefiles/tools/scripts needs awk, Perl, grep, sed,
zip, and other *nix utilities themselves, hence also the need for Cygwin...
> All the best
> Peter
>
>
>
Damjan