On 4/14/20 9:46 PM, Peter Kovacs wrote:
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.
HA! I guess I missed this. I was wondering if cmake might be acceptable
option, and I guess it is! :)
On Carl's original question. There WERE dependency specs in dmake. Since
I'm not a gbuild guru, I couldn't figure how this was handled in gbuild.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
