dejagnu version update?

Bernhard Reutner-Fischer rep.dot.nop@gmail.com
Wed Sep 16 19:09:00 GMT 2015


On September 16, 2015 7:39:42 PM GMT+02:00, David Malcolm <dmalcolm@redhat.com> wrote:
>On Wed, 2015-09-16 at 10:36 -0600, Jeff Law wrote:
>> On 09/16/2015 10:25 AM, Ramana Radhakrishnan wrote:
>> >
>> >
>> > On 16/09/15 17:14, Mike Stump wrote:
>> >> On Sep 16, 2015, at 12:29 AM, Andreas Schwab <schwab@suse.de>
>> >> wrote:
>> >>> Mike Stump <mikestump@comcast.net> writes:
>> >>>
>> >>>> The software presently works with 1.4.4 and there aren’t any
>> >>>> changes that require anything newer.
>> >>>
>> >>> SLES 12 has 1.4.4.
>> >>
>> >> Would be nice to cover them as well, but their update schedule,
>3-4
>> >> years, means that their next update is 2018.  They didn’t update
>to
>> >> a 3 year old stable release of dejagnu for their last OS, meaning
>> >> they are on a > 7 year update cycle.  I love embedded and really
>> >> long term support cycles (20 years), but, don’t think we should
>> >> cater to the 20 year cycle just yet.  :-)  Since 7 is
>substantially
>> >> longer than 2, I don’t think we should worry about it.  If they
>had
>> >> updated at the time, they would have had 3 years of engineering
>and
>> >> testing before the release and _had_ 1.5.
>> >>
>> >
>> > Sorry about the obvious (possibly dumb) question.
>> >
>> > Can't we just import a copy of dejagnu each year and install it as
>> > part of the source tree ? I can't imagine installing dejagnu is
>> > adding a huge amount of time to build and regression test time ?
>> > Advantage is that everyone is guaranteed to be on the same version.
>I
>> > fully expect resistance due to specific issues with specific
>versions
>> > of tcl and expect, but if folks aren't aware of this .....
>> That should work -- certainly that's the way we used to do things at 
>> Cygnus.  Some of that code may have bitrotted as single tree builds
>have 
>> fallen out-of-favor through the years.
>> 
>> As to whether or  not its a good idea.  I'm torn -- I don't like
>copying 
>> code from other repos because of the long term maintenance concerns.
>> 
>> I'd rather just move to 1.5 and get on with things. 
>
>AIUI, we specifically need >= 1.5.3 (or a version with a backport) to
>get support for multiple load_lib paths mentioned by Bernhard, which is
>what motivated this thread (on gcc-patches, before it spread to the gcc
>list):
> https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01196.html
> https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00983.html

And
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01395.html

Where Joseph said he'd wait some more.. I had thought I asked longer ago than that, time flies if one has fun.

I'd just require 1.5.3 just to avoid the time needed by folks to workaround those silly ordering gotchas and load cascades that propagate through the tree. Admittedly not my call but a pity IMHO.

Thanks,



More information about the Gcc-patches mailing list