[rfc] [icedtea-web] make links

[Deepak Bhole]

* Jiri Vanek <jvanek at redhat.com> [2012-05-17 14:40]:
> On 05/17/2012 05:47 PM, Deepak Bhole wrote:
> >* Jiri Vanek<jvanek at redhat.com>  [2012-05-17 04:25]:
> >>On 05/16/2012 06:58 PM, Deepak Bhole wrote:
> >>>* Jiri Vanek<jvanek at redhat.com>   [2012-05-11 08:52]:
> ...
> >>>>>
> >>>>>>>>  >    2.  It's still expecting the plugin to be in
> >>>>>>>>  >    $(DESTDIR)$(libdir)/$(BUILT_PLUGIN_LIBRARY),
> >>>>>>>>  >    the final install location.  It needs to link to to the copy in the
> >>>>>>>>  >    build directory.
> >>>>>>>  Hmm... I still believe I'm doing the correct thing. All Reproducers
> >>>>>>>  tests are run against $(DESTDIR).
> >>>>>Then they are wrong too.   I should be able to check it works before I
> >>>>>commit to installing it on my system.
> >>>>
> >>>>Well they are reproducers, they expect to be run on installed stuff.
> >>>>
> >>>
> >>>Is it possible to make them run without installation at all? e.g.
> >>>firefox can be told to look for plugins elsewhere with MOZ_PLUGIN_PATH
> >>
> >>Yes. And even link from mozilla-fs can be easily targeted to
> >>builddir.  It is not an blocker. There are two different issues:
> >>
> >>1 - design) the concept is to test installed application
> >>2 - implementation) [here I can be wrong, but I believe I'm not]
> >>inside javaws (not relevant but..) and inside IcedTeaPlugin.so are
> >>harcoded paths to installdir jars of netx. So To make it work form
> >>builddir I have to make build just for testing, what I believe is
> >>contra productive. So if I will link library from buildddir, it will
> >>still be necessary to have installed application (and so have jars
> >>in install dir where the so file is searching for them). I think
> >>that any hacking around to make it work is much worser then have
> >>installed application before reproducers runs.
> >>
> >
> >Can we do a fake install somewhere and run tests through there? My only
> >concern here is that if all I want to do is run tests, I am forced to
> >either consciously make sure I don't specify a system install prefix, or
> >to overwrite what is on the system already.
> 
> Yes. Fake install is solution. Actually current solution :).
> I consider --prefix as best. It is doing exactly what we need without complications.
> Testsuite is then run again s prefixed installdir.
> 

Sorry, I am confused.

--prefix? But so then aren't we back to the same problem of the user
having to remember to give a temp prefix if they want to 'make test' or
risk overwriting what is on the system?

Cheers,
Deepak

> J.
> >
> >Cheers,
> >Deepak
> >
> >>
> >>>
> >>>Cheers,
> >>>Deepak
> >>>
> >>>>ok now?
> >>>>>
> >>>>>>>>  >
> >>
> >>>Thanx for review!
> >>
> >>Thanx again for clarifying!
> >>
> >>
> >>J.
>