[L2Ork-dev] CI build times

[Jonathan Wilkes]

Ok, we've already got this:

> Cloning into '/home/user/builds/jwilkes/purr-data/Gem'...

So submodules shouldn't be a problem.

Hm... I wish I had checked for that in the previous build log before I
wrote over it. :)

-Jonathan

On Wed, Oct 21, 2020 at 10:54 AM Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>
> Ok, it seems to be chugging away. We'll see what happens:
>
> https://git.purrdata.net/jwilkes/purr-data/-/jobs/22565
>
> -Jonathan
>
> On Wed, Oct 21, 2020 at 10:43 AM Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
> >
> > On Tue, Oct 20, 2020 at 11:19 PM Albert Graef <aggraef at gmail.com> wrote:
> > >
> > > No, that build log is much too short. Maybe you haven't checked out the submodules? (See "Skipping Git submodules setup" in the log.)
> >
> > All I did was to replace the direct call to tar_em_up.sh in
> > .gitlab-ci.yml with a call to "make GEM_MAKEFLAGS=-j2". in the main
> > directory of the repo.
> >
> > If that doesn't automatically check out all the necessary submodules
> > then something is broken with either the toplevel makefile or with the
> > handling of the GEM_MAKEFLAGS variable.
> >
> > >
> > > In any case, the GEM_MAKEFLAGS option isn't to blame for that, I'm using that every time for Windows builds on my NUC, it works.
> >
> > Well, I'll go in and nuke any cached container I have and try again.
> >
> > -Jonathan
> >
> > >
> > > Albert
> > >
> > >
> > >
> > > On Tue, Oct 20, 2020 at 9:27 PM Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
> > >>
> > >> On Thu, Jul 30, 2020 at 1:13 PM Albert Graef <aggraef at gmail.com> wrote:
> > >>
> > >> > One thing that works really well, though, is building Gem in parallel which reduces build times dramatically.
> > >> > This is in the current build system, you can trigger it by invoking `make` in the toplevel source directory like
> > >> > so:
> > >>
> > >> > make GEM_MAKEFLAGS=-j8
> > >>
> > >> Even on my nuc with only 2 cores, setting "-j2" cuts the build time in half.
> > >>
> > >> Albert-- I'm suspicious whether it's even building Gem:
> > >>
> > >> https://git.purrdata.net/jwilkes/purr-data/-/jobs/22545/raw
> > >>
> > >> Where's the log of that slow, plodding libtool compilation that
> > >> usually looks like this:
> > >>
> > >> make[6]: Entering directory
> > >> '/home/user/builds/jwilkes/purr-data/Gem/src/Controls'
> > >>   CXX      libControls_la-gemframebuffer.lo
> > >>   CXX      libControls_la-gemcubeframebuffer.lo
> > >>   CXX      libControls_la-gemhead.lo
> > >>
> > >>
> > >> Also, I see this make message:
> > >>
> > >> make[6]: Entering directory '/builds/jwilkes/purr-data/Gem/src/Controls'
> > >> UNUSED SOURCES in .: libControls_la-gemhead.o
> > >> libControls_la-gemcubeframebuffer.o libControls_la-gemlist_info.o
> > >> libControls_la-gemlist_matrix.o libControls_la-gemmanager.o
> > >> libControls_la-gemreceive.o libControls_la-gemframebuffer.o
> > >> libControls_la-render_trigger.o libControls_la-gemlist.o
> > >> libControls_la-modelfiler.o
> > >>
> > >> Unfortunately, I can't be sure because Gem isn't hooked up to the
> > >> external creation tests yet.
> > >>
> > >> Anyhow, are you seeing build times cut in half by this optimization?
> > >>
> > >> -Jonathan
> > >> _______________________________________________
> > >> L2Ork-dev mailing list
> > >> L2Ork-dev at disis.music.vt.edu
> > >> https://disis.music.vt.edu/listinfo/l2ork-dev
> > >
> > >
> > >
> > > --
> > > Dr. Albert Gr"af
> > > Computer Music Research Group, JGU Mainz, Germany
> > > Email: aggraef at gmail.com, web: https://agraef.github.io/
> > > _______________________________________________
> > > L2Ork-dev mailing list
> > > L2Ork-dev at disis.music.vt.edu
> > > https://disis.music.vt.edu/listinfo/l2ork-dev