[kyukhin/gomp4-offload] DESTDIR issues

Hi!

It seems building of the host compiler requires the offloading compiler
to be installed directly in the prefix, which is something really
undesirable e.g. for distro builds where things are installed with
non-empty $(DESTDIR).
Right now it seems that for building all that is needed is
main_target_image.h.

Either we can do something like the following patch, i.e. look
at -I$(DESTDIR)/$(target_dir)/include first and fall back to
-I$(target_dir)/include, which fixed the build for me, but unfortunately
it violates GNU conventions:
https://www.gnu.org/prep/standards/html_node/DESTDIR.html
"DESTDIR should be supported only in the install* and uninstall* targets, as
those are the only targets where it is useful."
while this patch uses it during build.

Another option would be to have two different modes of building
--enable-offload-targets= compilers, one where you really have
all the offloading target compilers installed (with empty DESTDIR, or
initially with non-empty DESTDIR, then somehow (package manager, etc.)
copied to the right prefix), and another one where for each offloading
target you'd additionally specify the build directory containing
non-installed tree (dunno, could be e.g.
--enable-offload-targets=x86_64-intelmic-linux-gnu=/some/path,ptx-none=/some/other/path
format?) and let the host compiler's build look into the other build trees
for what it needs during building and/or testing (for building 
main_target_image.h should be supposedly all that is needed, for testing
perhaps more).

Thoughts on this?

2014-09-17  Jakub Jelinek  <jakub@redhat.com>

	* plugin/Makefile.am (libgomp_plugin_mic_la_CPPFLAGS): Use
	$(DESTDIR)$(target_dir)/include path before
	trying $(target_dir)/include.
	* plugin/Makefile.in: Regenerated.


	Jakub

Il 17/09/2014 15:31, Jakub Jelinek ha scritto:
> It seems building of the host compiler requires the offloading compiler
> to be installed directly in the prefix, which is something really
> undesirable e.g. for distro builds where things are installed with
> non-empty $(DESTDIR).

Is the offloading compiler built together with GCC or previously?  If
the latter, what's the difference between the offloading compiler and
say gmp?  Setting the LD_LIBRARY_PATH would be the responsibility of
whoever builds GCC; it would be the same here for the COMPILER_PATH.

> Either we can do something like the following patch, i.e. look
> at -I$(DESTDIR)/$(target_dir)/include first and fall back to
> -I$(target_dir)/include, which fixed the build for me, but unfortunately
> it violates GNU conventions:
> https://www.gnu.org/prep/standards/html_node/DESTDIR.html
> "DESTDIR should be supported only in the install* and uninstall* targets, as
> those are the only targets where it is useful."
> while this patch uses it during build.

I agree with the coding standards.  The right way to do it could be a
configure option, if it's really not possible to leave it to whoever
builds GCC.

Paolo

On Wed, Sep 17, 2014 at 04:04:25PM +0200, Paolo Bonzini wrote:
> Il 17/09/2014 15:31, Jakub Jelinek ha scritto:
> > It seems building of the host compiler requires the offloading compiler
> > to be installed directly in the prefix, which is something really
> > undesirable e.g. for distro builds where things are installed with
> > non-empty $(DESTDIR).
> 
> Is the offloading compiler built together with GCC or previously?  If
> the latter, what's the difference between the offloading compiler and
> say gmp?  Setting the LD_LIBRARY_PATH would be the responsibility of
> whoever builds GCC; it would be the same here for the COMPILER_PATH.

Right now previously, but (usually) from the very same sources, so I think
it will be usually (but not always?) desirable to build them together, perhaps
not in a single toplevel configure and single toplevel make.

	Jakub

Il 17/09/2014 16:09, Jakub Jelinek ha scritto:
>> > Is the offloading compiler built together with GCC or previously?  If
>> > the latter, what's the difference between the offloading compiler and
>> > say gmp?  Setting the LD_LIBRARY_PATH would be the responsibility of
>> > whoever builds GCC; it would be the same here for the COMPILER_PATH.
> Right now previously, but (usually) from the very same sources, so I think
> it will be usually (but not always?) desirable to build them together, perhaps
> not in a single toplevel configure and single toplevel make.

If it's from the same sources, that probably rules out a single toplevel
configure/make.  Is it a problem if a newer GCC is compiled with older
headers from the offloading compiler?

In any case, I would go with a configure option.

Paolo

Ok, the approach with additional --enable-offload-targets arguments seems to be
more appropriate, so I will fix offloading infrastructure pach #1.

Thanks,
  -- Ilya