If one wants to tap in our build system he needs to understand Perl,
shell, make, ant, XML, configure, ...
This is just way to complicated, especially if you want to bring in an
IDE to ease code development.
Damjan is not very happy with the features gmake offers. I am not sure
where exactly the Issue is.
He is opting for SCONs, with the option to extend the build system with
python. And IMHO on Damjan
Side he is quite serious about it.
Everyone else has not expressed any opinion on this development, so I am
not sure everyone is aware. The last discussion on this topic,
consent has been strongly to make gmake work.
Another objection is that we got some heavy negative experience report
from the serf community about SCONS.
Which are switching from, SCONS to cmake.
So in the end we do not have Consent where we want to go. And currently
it is heavily influenced by Damjan. And this is imho very thin.
I am still like the Idea most to go in the direction of ant / maven,
despite its flaws. But I am not negative on SCONS either. My main point
is we need something that
offers a better architecture and is easier to handled and maintained.
Also what we could try is making use of something like portage. Portage
is pretty easy to use repostory manager used by gentoo, whioch also had
a community prior to homebrew on mac. It is not very difficult to
setup. But it is build to make different build system work together. So
we could have a build repository, that builds our dependencies. We
reconstruct our monolith in smaller build libraries, like UNOcore,
OOFrame, UNOGUI, OOapp, OOpython, StarBasic, OOwizards, extentionXYZ
(Just saying something), and pick the best build system (cmake, gmake,
ant, maven, SCONS) for each library. Also we could think on incubating
Starbasic or UNO, as own Project if they become more interesting. Since
Portage is made for source build, but can also handle binaries, maybe we
could add some features that will make it easy to export towards
specific distributions, making it easy for distributors to export to
their system. BTW, portage is build on python, so it should work on all
systems we target. Sorry if this Idea is to crazy for you. It is only an
idea.
Maybe it is a good time now to bring this topic up in everyones mind.
All the Best
Peter
Am 15.04.20 um 01:14 schrieb Carl Marcum:
On 4/14/20 5:53 PM, Kay Schenk wrote:
On 4/14/20 1:46 PM, Carl Marcum wrote:
On 4/14/20 3:57 PM, Peter Kovacs wrote:
You could try to build only the module, by going into the folder
and execute make directly.
Hi Peter,
Yes but that doesn't solve my problem with targets not running in
order or how I can enforce it if possible.
I don't want to break the build if my change ever makes it to trunk.
Eventually if I can get Ant to build the Jar exactly as gbuild does
I can use that one and my problem goes away.
But until then I was wanting to use the current one that gbuild builds.
Thanks,
Carl
Hi Carl --
From your first post in this thread...
When I build with "build --all" everything works as expected.
When I build with "build --all -P2 -- -P2" the file copy fails
because the juh.jar file isn't completed.
I recall having issues with the second part -- -P2.
You might try omitting that, and just use "build --all -P2" or maybe
"build --all -P4"
ref...
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO#Building_2
The build will take a longer but you shouldn't run into the
"non-completion" issue you're having.
Hope this helps,
Kay
Hi Kay,
Thanks for pointing out what the second parameter meant :)
It would still be good to know if it's possible to declare
dependencies between targets in gbuild somehow like you can with Ant
builds.
I'm guessing any final solution that gets into trunk has to build with
multiple threads per module.
My best option is probably to do the jar build along with the other
tasks in Ant so I can control when it happens.
Were already using Ant to build java jars in ridljar, jurt,
officebean, and probably other modules.
I didn't mention it but I'm working on creating the necessary javadoc,
source, and library jars for distribution through Apache Nexus [1].
But during the build process to avoid the need for a separate Vote
next time around.
[1] https://wiki.openoffice.org/wiki/Uno/Java/MavenBundles
Thanks again,
Carl
---------------------------------------------------------------------
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
