discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Reorganization of gnuradio-examples in trunk r627


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] Reorganization of gnuradio-examples in trunk r6279
Date: Tue, 4 Sep 2007 14:08:06 -0700
User-agent: Mutt/1.5.9i

On Wed, Sep 05, 2007 at 05:05:21AM +0930, Berndt Josef Wulf wrote:
> On Wednesday 05 September 2007 04:03:23 Johnathan Corgan wrote:
> > Berndt Josef Wulf wrote:
> > > Can we also add a switch that enables building individual modules
> > > "outside" the source tree the way it was prior to GNU-Radio 3.0.2?
> >
> > The way it was prior to 3.0.2 (or maybe it was 3.0.3) was broken.  The
> > 'make check' process could fail because of linkage outside the tree vs.
> > inside during a build.
> >
> 
> That's why I suggested a configure argument switch, which is disabled by 
> default. It would make life lot easier for package builder, well at least for 
> those that do not want to build monolithic packages. Its easy to implement 
> and has no impact on current methodology whatsoever, as it would require a 
> conscious decision in getting this wrong!
> 
> > > This will allow building packages as individual modules.
> >
> > I understand the benefit this would have; we will at least reexamine it
> > after the 3.1 release, but no promises.
> 
> You make my request sound like a complex issue similar to that of an API 
> change. It merely adds another configure option, which only requires a couple 
> of minor changes in the configure script and Makefile.common file.
> 
> cheerio Berndt

Hi Berndt,

Right now Johnathan and I are dealing with getting 3.1 out the door.
We think that a good, solid solution to the problem is more
complicated than you do.  We understand what you want to do, and we
want to keep the ability to test against non-installed code.  Thus, a
solution requires the ability to do both.

If you think that we've missed the boat on the complexity, I'd
certainly welcome a patch (after 3.1 is out), that implements what you
want, as long as it still supports the existing behavior.  Assuming you
come up with a patch that works well, I don't see any reason that it
couldn't go into 3.1.1.

Eric




reply via email to

[Prev in Thread] Current Thread [Next in Thread]