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

[Jeff Law <law@redhat.com>]

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.


>
> 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.

>
> 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.

jeff