Building out of tree results in build products in original source tree

[prakashsurya]

Building the modules out of tree leaves the original source tree tainted with build products. For example:

# Run from within SPL source directory
$ sh autogen.sh 
$ git ls-files -o
Makefile.in
aclocal.m4
autom4te.cache/output.0
autom4te.cache/output.1
autom4te.cache/requests
autom4te.cache/traces.0
autom4te.cache/traces.1
cmd/Makefile.in
config/config.guess
config/config.sub
config/depcomp
config/install-sh
config/ltmain.sh
config/missing
configure
include/Makefile.in
lib/Makefile.in
scripts/Makefile.in
spl_config.h.in

# Run from temporary "build" directory outside of SPL source tree
$ $SPL/configure && make

# Run from within SPL source directory
$ git ls-files -o
Makefile.in
aclocal.m4
autom4te.cache/output.0
autom4te.cache/output.1
autom4te.cache/requests
autom4te.cache/traces.0
autom4te.cache/traces.1
cmd/Makefile.in
config/config.guess
config/config.sub
config/depcomp
config/install-sh
config/ltmain.sh
config/missing
configure
include/Makefile.in
lib/Makefile.in
module/spl/.spl-atomic.o.cmd
module/spl/.spl-condvar.o.cmd
module/spl/.spl-cred.o.cmd
module/spl/.spl-debug.o.cmd
module/spl/.spl-err.o.cmd
module/spl/.spl-generic.o.cmd
module/spl/.spl-kmem.o.cmd
module/spl/.spl-kobj.o.cmd
module/spl/.spl-kstat.o.cmd
module/spl/.spl-mutex.o.cmd
module/spl/.spl-proc.o.cmd
module/spl/.spl-rwlock.o.cmd
module/spl/.spl-taskq.o.cmd
module/spl/.spl-thread.o.cmd
module/spl/.spl-time.o.cmd
module/spl/.spl-tsd.o.cmd
module/spl/.spl-vnode.o.cmd
module/spl/.spl-xdr.o.cmd
module/spl/.spl-zlib.o.cmd
module/spl/spl-atomic.o
module/spl/spl-condvar.o
module/spl/spl-cred.o
module/spl/spl-debug.o
module/spl/spl-err.o
module/spl/spl-generic.o
module/spl/spl-kmem.o
module/spl/spl-kobj.o
module/spl/spl-kstat.o
module/spl/spl-mutex.o
module/spl/spl-proc.o
module/spl/spl-rwlock.o
module/spl/spl-taskq.o
module/spl/spl-thread.o
module/spl/spl-time.o
module/spl/spl-tsd.o
module/spl/spl-vnode.o
module/spl/spl-xdr.o
module/spl/spl-zlib.o
module/splat/.splat-atomic.o.cmd
module/splat/.splat-condvar.o.cmd
module/splat/.splat-cred.o.cmd
module/splat/.splat-ctl.o.cmd
module/splat/.splat-generic.o.cmd
module/splat/.splat-kmem.o.cmd
module/splat/.splat-kobj.o.cmd
module/splat/.splat-linux.o.cmd
module/splat/.splat-list.o.cmd
module/splat/.splat-mutex.o.cmd
module/splat/.splat-random.o.cmd
module/splat/.splat-rwlock.o.cmd
module/splat/.splat-taskq.o.cmd
module/splat/.splat-thread.o.cmd
module/splat/.splat-time.o.cmd
module/splat/.splat-vnode.o.cmd
module/splat/.splat-zlib.o.cmd
module/splat/splat-atomic.o
module/splat/splat-condvar.o
module/splat/splat-cred.o
module/splat/splat-ctl.o
module/splat/splat-generic.o
module/splat/splat-kmem.o
module/splat/splat-kobj.o
module/splat/splat-linux.o
module/splat/splat-list.o
module/splat/splat-mutex.o
module/splat/splat-random.o
module/splat/splat-rwlock.o
module/splat/splat-taskq.o
module/splat/splat-thread.o
module/splat/splat-time.o
module/splat/splat-vnode.o
module/splat/splat-zlib.o
scripts/Makefile.in
spl_config.h.in

[prakashsurya]

oops.. I meant to open this in the SPL project. I'd guess both trees suffer from the same defect though.

[ryao]

Could the problem be that you are not passing --with-linux-obj=?

[prakashsurya]

I don't think so. Why would that option change anything?

[ryao]

That tells the kernel build system where the object build directory is. The default is the Linux source tree, but it can be some place else.

[behlendorf]

@ryao The issue here isn't locating the kernel objects, the problem is the resulting spl/zfs objects are being created in the spl/zfs source tree. They should be created in the alternate build directory.

[FransUrbo]

I've looked at trying to fix this for quite a few hours now, but there seems NO way to run autoreconf in anything but the source directory....

I've tried

# mkdir build
# cd build
# ln -s ../configure.ac .
# ln -s ../config .
# autoreconf -fiv

but nothing I've tried worked :(.

Anyone know how to run autoreconf inside an empty directory?

[behlendorf]

We shouldn't need to run autoreconf outside the source tree. It's OK for the autoreconf products (*.in, *.m4, files, ./config/ scripts, etc) to exist in the source tree. They aren't tried to a specific build and you'd expect them to be part of any distributed tarball. The issue are the *.o and *.cmd files which should be in the build NOT source directory.

[FransUrbo]

Ok, if we're ok with the autoreconf results in the source dir, then I'll see what I can do.

[FransUrbo]

That was surprisingly simple! :). @prakashsurya could you test the pull requests I just issued? There's one for SPL and one for ZFS.

[behlendorf]

@FransUrbo Sure, anything which is part of the make dist tarball can stay in the source directory. It's not tied to any specific build.

The patch almost worked for me. It correctly handled everything for the user space build but since every under module/ rely on the kernel build system it didn't work there. I still see the .o and .cmd files in the source directory there. There's probably some equivalent but of magic we need to set for these Makefile.ins.

[FransUrbo]

I suspected as much (an hour or so after I submitted the pull request :), but I didn't remove the .gitignores so I didn't see them in the status. I'll update those Makefile.ins as well...

[FransUrbo]

I've done a force push that really don't leave any build results in the source directory (I missed some because I haven't tested by removing the .gitignore files which filters out a lot).

I still don't know how to fix the module directory... But the base for it should be there.

[FransUrbo]

Managed to find the solution for modules. Instead of VPATH, use

src = @abs_top_srcdir@/module/<moduledir>
obj = @abs_builddir@

Please test the new commits and comment.

[FransUrbo]

These latest ones aren't as pretty and simple as the first (they remove basically all paths to code etc and instead rely on the VPATH/src/obj variables).

[FransUrbo]

I've added some changes to config/kernel.m4 to be able to find the build directory (for a VPATH build). I've added it as a separate commit, in case you don't like it...

[behlendorf]

Oh, that's a much bigger change. Definitely something for after 0.6.3, I'll look at after the tag.

[FransUrbo]

Oh, I didn't think for a moment even that simple one I posted first would end up in 0.6.3! :). You need to stop accepting more, and get it rolled out already :D

[behlendorf]

@FransUrbo thanks for doing the heavy lifting on this one. I ended up having to slightly modify your patch to cleanly handle the libraries which have source which isn't co-located with the Makefile but I was able to sort it out. This have been merged to master and I have to say it's a nice improvement.

[FransUrbo]

@FransUrbo thanks for doing the heavy lifting on this one.

No worries.

I was thinking that we could/should get rid of the .gitignore files eventually to. With this, they shouldn't be needed.

On the other hand, maybe not everyone chooses to do the build in a sub directory..

[behlendorf]

The .gitigore files are pretty standard fare these days. Unless a better solution comes along I think those are here to stay.

[FransUrbo]

Worst problem I have with the .gitignore files is that a simple git clean doesn't really CLEAN everything.

But it was just a thought...

[behlendorf]

@FransUrbo Ahh, that's what the -x option is for. I use git clean -dxf to wipe everything clean.