[rfc] [icedtea-web] make links

Deepak Bhole dbhole at redhat.com
Thu May 17 12:17:43 PDT 2012


* Jiri Vanek <jvanek at redhat.com> [2012-05-17 15:15]:
> On 05/17/2012 09:04 PM, Deepak Bhole wrote:
> >* 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?\
> 
> Yes we are. What do you think about stopping of testsuite in case that prefix will not be specified?
> But I'm confused to. Normal user will never run run-netx-dist-tests. This family of targets will be always run by someone who understand the stuff. And if not, it will not make any harm. I still do not understand why is it so evil to test installed application (as eg jtreg is dooing).
> 

Oh it is not evil. I have nothing against testing an installed
application. I just want to make sure that something as innocuous as
'make test' is not going to nuke my system installation.

Cheers,
Deepak

> Looking forward for "whats going to happen" :)
> J.



More information about the distro-pkg-dev mailing list