On 04.11.2013 16:53, janI wrote:
On Nov 4, 2013 4:41 PM, "Jürgen Schmidt" <jogischm...@gmail.com> wrote:
On 11/4/13 3:46 PM, janI wrote:
On Nov 4, 2013 3:31 PM, "Andre Fischer" <awf....@gmail.com> wrote:
On 04.11.2013 10:36, janI wrote:
Hi
I agree to using ratscan on trunk is a good idea, and all the other
comments.
But my original question is still not answered, do we use the build
system
to do ratscan, or is the ratscan target an old relict ?
I think that I have added the ext_libraries/ratscan/ module. It is
built and started when the --with-rat-scan option is given to configure.
But I don't know if that is used on our build servers. If you see a
--with-rat-scan option in their configuration files then it is,
otherwise
it is not.
thx for a clear answer.
yes it is added to ext_librararies, and currently not used, so I will
remove it in my branch (r.i.p. build.pl efford)
what do you mean it is not used? Do you know all configure options from
people? I think the main idea was to make it as easy as possible for
people to run their own local ratscan. I see no reason why we should
remove it. Today anybody can run it with this configure option, how doe
sit wok without this in a local environment (no build bot involved)?
no I dont, and with your statement we can forget about changing anything!
there will alwayes be someone using whatever we remove.
My idea, which got good response was to only implement build options we use
to build our releases and potentially a few extra used by active aoo
developers.
I think that we are talking about two things. One is build.pl (or its
successor) and the other is configure et al. The only discussion I can
recall was about build.pl.
Cleaning up both is certainly a good idea, and dropping some or many
options would also be good. But I think that keeping only those options
that we use for building releases is too restrictive. Building developer
builds is done much more often then building a release. Different
developers need different options on their machines. So we have to be
careful about what is dropped and what is kept.
ratscan is really a good example of something that do not belong in a build
system, we also do not include svn, which seems more relevant in a build
system
I disagree. Ratscan is used as a sort of unit test. We can release
only when the ratscan is OK. Developers may want to run it on their
local machines to know if they break the ratscan. I consider that a
vital part of a build system.
I don't see the similarity to SVN.
If I am wrong, and we shall support all options in the future, there are no
idea in trying to remove build.pl.
There is a place between no cleanup and removing all options that are
not used for building releases. It just is not easy or straightforward
to find. You started that discussion for build.pl and I think we found
consensus. A discussion about configure will probably be longer and
more difficult because there are so much more options, some of which are
a bit arcane.
But you are probably right to assume that this is no area where you (or
anyone else) can make everybody happy :-)
-Andre
rgds
jan i
Juergen
rgds
jan i
-Andre
rgds
jan I.
---------------------------------------------------------------------
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
