Re: builddir != srcdir in jhbuild breaks my workflow

[Emmanuele Bassi <ebassi gmail com>]

Hi;

On 30 August 2016 at 18:23, Sébastien Wilmet <swilmet gnome org> wrote:
> Hi,
>
> With the new jhbuild default configuration, it builds the module with
> scrdir != builddir. I wanted to explain why I don't like it, and why
> I've put the following in my jhbuildrc:
>
> checkoutroot = os.path.expanduser('~/gnome')
> buildroot = os.path.expanduser('~/gnome')
>
> (to have again builddir == scrdir)

That's not really how it's done.

Just set:

  buildroot = None

and jhbuild will use the srcdir by default.

> Here is my workflow (but I'm sure other developers do the same):
>
> 1) Once a project is fully built, to re-build something I always do
> something along those lines:
>
> To compile only what I need:
> <inside git repo, in my 'build' terminal tab>
> $ jhbuild shell
> [jhbuild] $ cd src/
> [jhbuild] $ make
>
> To re-build only a certain *.c file, to see if there are any warnings:
> [jhbuild] $ touch file.c
> [jhbuild] $ make

If you use:

  jhbuild make

instead of entering inside a shell, jhbuild would pick up the changes
and build in the build directory.

> You see that that workflow relies heavily on builddir == srcdir.

Obviously there are times when builddir == srcdir. For instance, if
I'm hacking on an uninstalled component, I'll likely get into a
`jhbuild shell` and just `configure && make`. This is perfectly fine,
and jhbuild does not require configuration changes to allow you to do
so.

> So, builddir != srcdir breaks my workflow. There are probably other
> examples, the above two are the most common to me.

And you can disable that behaviour, as you found out.

For the vast majority of other cases, though, builddir != srcdir is
simply the best option we currently have, as long as we use autotools,
to figure out build issues that happen:

 * at distcheck time
 * when distributors package our software
 * when building Flatpaks

We could avoid all of this by switching to other build systems, like
CMake or (better) Meson, that use separate build directories by
default.

Or you could configure your jhbuild to use builddir == srcdir, like you did.

> In GNOME, GNOME Continuous needs to be (continuously) babysitted, it
> doesn't send automatic mails to the right people. That's the root of the
> problem.

No, it's not the root of anything. I notify of breakage and file bugs;
it's definitely less automated than I'd like, but most of the time I'm
also the person that knows how to fix these issues — because if
developers knew how to fix the issue in the first place they wouldn't
be pushing code that breaks the build if the build directory is not
the source directory.

The reason why Continuous breaks is because developers have to deal
with this build system anti-pattern; Continuous, in this case, is just
a late-warning system.

An early-warning system is, on the other hand, something that warns
you before you push to the remote git repository — which is what
jhbuild is.

> Enabling builddir != srcdir by default in jhbuild is just a
> workaround. With git clean -Xdf, there is really no need to build in a
> separate directory.

Sorry, this is simply not true. Things like built files, internal
dependencies, or inclusion paths are never going to be resolved by a
`git clean -xdf`, and those are the usual things that break under
builddir != srcdir.

> Finding builddir != srcdir issues early is nice, but for me it hinders
> my workflow too much.

Then you can revert the configuration change in your own local
configuration, since it's just a default.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]