Re: [PATCH 2/5] gcc: configure and Makefile changes needed by jit

[David Malcolm <dmalcolm@redhat.com>]

On Wed, 2014-10-15 at 14:51 -0600, Jeff Law wrote:
> On 10/15/14 12:25, David Malcolm wrote:
> > On Wed, 2014-10-15 at 11:36 -0600, Jeff Law wrote:
> >> On 10/13/14 11:45, David Malcolm wrote:
> >>> gcc/ChangeLog:
> >>> 	* configure.ac (gcc_version): Expose this value for use via
> >>> 	AC_SUBST, since the jit code needs it within the new file
> >>> 	libgccjit.pc.in.
> >>> 	(doc_build_sys): New variable, set to "sphinx" if
> >>> 	sphinx is installed, falling back to "texinfo" otherwise.
> >>> 	(gcc-driver-name.h): Generate a gcc-driver-name.h file containing
> >>> 	GCC_DRIVER_NAME for the benefit of jit/jit-playback.c.
> >>> 	* configure: Regenerate.
> >>> 	* Makefile.in (doc_build_sys): New.
> >>> 	(bindir): New.
> >>> 	(pkgconfigdir): New.
> >>> 	(installdirs): Add creation of $(DESTDIR)$(pkgconfigdir).
> >>> 	(site.exp): When constructing site.exp, add a line to set "bindir".
> >> Mostly OK.  Though a couple questions.
> >>
> >> Why do we need pkgconfig and why do you need a bindir in site.exp?
> >
> > I chose to provide a libgccjit.pc file in the install, so that client
> > code has the option of compiling and linking against the library like
> > this:
> >
> > $ gcc jit-hello-world.c $(pkg-config libgccjit --cflags)
> > $ gcc jit-hello-world.o $(pkg-config libgccjit --libs)
> WIthout a general consensus to add pkg-config, I'd rather not go this 
> direction.  Right now I'd much rather see us adding the appropriate 
> flags automatically.

How could we do that automatically?  The reason I wanted to use
pkg-config here is not for us, it's for the users of the jit library,
e.g. GNU Octave, my "coconut" jit for CPython etc.  I don't want to
require clients of this code to use the GNU autotools (for example, the
Python bindings don't).

How do *they* select the correct include paths and linker flags for
building against libgccjit?  It's easy if the relevant files got put
into /usr/include and /usr/lib, but there could be multiple versions
installed in different prefixes for different development stacks.
pkg-config solves this by having the user set up PKG_CONFIG_PATH to pick
up the relevant .pc files for each library.

[well, it's also for *me* when I'm using the library, in that I've made
use of the pkg-config approach quite a bit since adding the support]


> > relying on pkg-config to automatically supply the relevant flags for the
> > correct paths (for those people who want to use pkg-config).
> But I think that is a completely independent discussion and if we go 
> that direction we should make it pervasive in GCC and not just for the 
> JIT bits.

I think that the jit is a special case here: I don't know of any other
shared libraries built from the gcc codebase that are intended to run on
the host, and are for use by 3rd-party libraries/binaries.  (though to
be fair, the jit rather blurs the host/build line).

But if this is going to block acceptance of the branch I can drop it;
client code can always just manually specify the -I and -l/-L
accordingly.

> > As for the "bindir" in site.exp, Joseph asked me when the library
> > invokes a driver to convert from .s to .so to:
> >
> > On Tue, 2014-09-23 at 23:27 +0000, Joseph S. Myers wrote:
> >> * use the $(target_noncanonical)-gcc-$(version) name for the
> >> driver rather than plain "gcc", to maximise the chance that it
> >> is actually the same compiler the JIT library was built for (I
> >> realise you may not actually depend on it being the same
> >> compiler, but that does seem best; in principle in future it
> >> should be possible to load multiple copies of the JIT library
> >> to JIT for different targets, so that code for an offload
> >> accelerator can go through the JIT).
> > ( https://gcc.gnu.org/ml/jit/2014-q3/msg00033.html )
> >
> > This full name is used when *installing* the driver, but doesn't exist
> > within the build directory.
> > Hence when running the library, the installation bindir needs to be in
> > the PATH.  In particular, (in
> > https://gcc.gnu.org/ml/jit/2014-q4/msg00005.html ) when running the jit
> > testsuite we rely on the driver having been installed, and in jit.exp we
> > need to temporarily prepend the installation bindir onto the front of
> > PATH when running test programs linked against libgccjit.so.  Hence we
> > need to know what bindir is from expect, hence we add it to site.exp.
> So if I'm reading all this correctly, what's being implied is that 
> testing is done using the installed bits rather than the in-build-tree 
> bits?  We really need this to run without having been installed.

One approach here might be to do make a copy of the driver binary with
the final name within the *build* dir (e.g.
"x86_64-unknown-linux-gnu-gcc-5.0.0").

Another might be the "run the driver code in-process" approach I dabbled
with here:
  https://gcc.gnu.org/ml/jit/2014-q3/msg00049.html
though that's some way from working, and is more invasive (no-one
replied to that email)