openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damjan Jovanovic <dam...@apache.org>
Subject Re: [Discussion] build tool
Date Tue, 05 Sep 2017 15:59:57 GMT
On Tue, Sep 5, 2017 at 4:11 PM, Peter Kovacs <petko@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message