Luboš Luňák wrote:
> Backwards compatibility. That includes Jenkins builds (all branches
> use the same setup, right?).
>
Perhaps a good idea then to introduce a CI driver scriptlet (or
target) into core?
I can imagine that might come in handy, given perhaps large-scale
rework of the build system
On 17/03/2020 15:43, Luboš Luňák wrote:
On Tuesday 17 of March 2020, Stephan Bergmann wrote:
* Why merely deprecate slowcheck, instead of removing it completely?
Backwards compatibility.
...after
On Tuesday 17 of March 2020, Stephan Bergmann wrote:
> On 17/03/2020 11:35, Luboš Luňák wrote:
> > So, proposal: 'slowcheck' will be deprecated and will simply map
> > to 'unitcheck', and 'unitcheck' will be the target to get just the "fast"
> > checks. 'check' will map to 'unitcheck slowcheck
On 17/03/2020 11:35, Luboš Luňák wrote:
So, proposal: 'slowcheck' will be deprecated and will simply map
to 'unitcheck', and 'unitcheck' will be the target to get just the "fast"
checks. 'check' will map to 'unitcheck slowcheck subsequentcheck uicheck'
also in modules. That would be consistent
On Thursday 05 of March 2020, Markus Mohrhard wrote:
> Hey,
>
> * Changing the default ‘make’ target (Lubos)
>
> > + https://gerrit.libreoffice.org/c/core/+/89820
> > + keeping ‘make check’ unchanged
> > + plain ‘make’ would just build, not run tests
> > + buildbot owners: need to run
Hi,
On Tue, Mar 10, 2020 at 04:21:26PM +0100, rene.engelh...@mailbox.org wrote:
> Probably because it depends on "build" which we probably patch out for
> obvious reasons (we have the jars built and run against /usr/lib/libreoffice)
> and thus if build doesn't run the test anymore just the java
Am 10. März 2020 14:16:26 MEZ schrieb Stephan Bergmann :
>
>> make subsequentcheck does only run java tests: cf.
>https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/blob/master/tests/junit.
>That one results in
On 10/03/2020 11:02, Jan-Marek Glogowski wrote:
But honestly: why do we want to have subsequentcheck at all, and not
just run all tests after the build. This would get rid of all the
use_more_fonts and whatever over hacks currently exist. The machine
should be busy enough building LO. Eventually
On 10/03/2020 13:19, rene.engelh...@mailbox.org wrote:
Am 10. März 2020 10:25:50 MEZ schrieb Stephan Bergmann :
On 06/03/2020 16:31, Rene Engelhard wrote:
And i think https://gerrit.libreoffice.org/c/core/+/88833 should then
be
done, too, as it makes it more clear (what is a
On 10/03/2020 10:47, Michael Stahl wrote:
On 10.03.20 10:25, Stephan Bergmann wrote:
After the transition from the two-stage dmake-based build system to
gbuild was completed, this could have been cleaned up, moving the
relevant dependencies into the individual tests.
this was actually done
Am 10. März 2020 10:25:50 MEZ schrieb Stephan Bergmann :
>On 06/03/2020 16:31, Rene Engelhard wrote:
>> And i think https://gerrit.libreoffice.org/c/core/+/88833 should then
>be
>> done, too, as it makes it more clear (what is a "subsequentcheck"?)
>and
>> would be a good rationale to rename
>>
Am 10.03.20 um 10:47 schrieb Michael Stahl:
> On 10.03.20 10:25, Stephan Bergmann wrote:
>> After the transition from the two-stage dmake-based build system to
>> gbuild was completed, this could have been cleaned up, moving the
>> relevant dependencies into the individual tests.
>
> this was
On 10.03.20 10:25, Stephan Bergmann wrote:
After the transition from the two-stage
dmake-based build system to gbuild was completed, this could have been
cleaned up, moving the relevant dependencies into the individual tests.
this was actually done for new tests and turned out to be a
On 06/03/2020 16:31, Rene Engelhard wrote:
And i think https://gerrit.libreoffice.org/c/core/+/88833 should then be
done, too, as it makes it more clear (what is a "subsequentcheck"?) and
would be a good rationale to rename
Hi,
On Fri, Mar 06, 2020 at 09:22:51AM +0100, Miklos Vajna wrote:
> On Fri, Mar 06, 2020 at 01:50:06AM +0800, Markus Mohrhard
> wrote:
> > Is there still a reason to have independent unitcheck and slowcheck
> > targets? They are historically different because a default module level
> > make
Hi Markus,
On Fri, Mar 06, 2020 at 01:50:06AM +0800, Markus Mohrhard
wrote:
> Is there still a reason to have independent unitcheck and slowcheck
> targets? They are historically different because a default module level
> make would only execute the unitcheck and not the slowcheck target but if
Hey,
* Changing the default ‘make’ target (Lubos)
> + https://gerrit.libreoffice.org/c/core/+/89820
> + keeping ‘make check’ unchanged
> + plain ‘make’ would just build, not run tests
> + buildbot owners: need to run ‘make unitcheck slowcheck’ on
> Windows/macOS, not just plain ‘make’ to
* Present:
+ Eike, Thorsten, Heiko, Michael S, Gabriel, Ilmari, blendergeek, Michael
W, Caolan, Olivier, Xisco, Miklos
* Completed Action Items:
+ Update VS baseline to 2019 in git (Stephan)
+ Install current VS2019 on build bots / Jenkins (Cloph, Thorsten)
+ Enable skia by default
18 matches
Mail list logo
