[Top][All Lists]
[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