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)
