[rfc] [icedtea-web] make links

[Jiri Vanek]

On 05/17/2012 09:42 PM, Deepak Bhole wrote:
> * Jiri Vanek<jvanek at redhat.com>  [2012-05-17 15:28]:
>> On 05/17/2012 09:17 PM, Deepak Bhole wrote:
>>> * 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.
>>
>> Tests will definitely not! I also do not believe  make links will do not harm. They are linking and unlinking correctly. And are linking correct stuff to correct place. Maybe I should run unlink*  after each test run (but I dont like this idea)? Now the unlink is depending on make clean. But make links must be called manually, so there is no danger of being invoked by mistake. And if icedte-web is linked incorrectly there is test to catch it.
>>
>
> What if something goes wrong during testing and it exits before
> unlinking? The user system would be set to use the wrong plugin -- worse
> yet, it could be without the user's knowledge.

agree - but form this point of view I'm doing the best thing right now.

make
make check
make install
make links //must be run manually
make run-netx-dist-tests  //if  links point to something not installed by this make install, then 
there is tests to catch this. If there are no correct links all browser tests will fail
make unlink (or make clean) //make unlink *restores* previous configuration

>
> Cheers,
> Deepak
>
>> J.
>>>
>>> Cheers,
>>> Deepak
>>>
Looking forward for "whats going to happen" O:)
J.
>>