This is a bug fix and very minor enhancement release to the existing 3.0
stable branch. All relevant issues that have been corrected on the main
development trunk have been back-ported.
Details on the changes since release 3.0.3rc1 are listed here:
latest release candidate breaks when compiling individual packages. This
is
due to intree dependencies that are nolonger satisfied under the
following
condition, e.g.:
Do the packages install the .la file? Perhaps some sort of
conditional that uses in-tree for configured component and in-$libdir
for unconfigured components would be the right thing.
Is it your assumption that we’d always build using the build-tree
includes?
I didn’t think about that much, but the above suggestion results in
using the build-tree includes. Arguably the installed includes for
just those components should be used, but CPPFLAGS isn’t powerful
enough to do that. In practice it doesn’t matter, since pkgsrc and
hopefully other packaging system using this technique would have all
packages consistently built from the same release tarball.
On Tue, Feb 27, 2007 at 11:39:36AM +1030, Berndt Josef W. wrote:
gmake[4]: Entering directory /usr/pkgsrc/ham/gnuradio-audio-oss/work/gnuradio-3.0.3rc2/gr-audio-oss/src' gmake[4]: *** No rule to make target…/…/gnuradio-core/src/lib/libgnuradio-core.la’, needed by `_audio_oss.la’.
Stop.
FYI, this isn’t new behavior. It’s been like this (or should have
been like this) since the build system overhaul.
I understand your desire to build individual pieces, but that hasn’t
been coded up yet.
I beg to differ. It worked within the pkgsrc environment and only broke in
recent RC2.
Yes, it appears this was “accidentally” working before, as we were
allowing the system library paths to be included when building inside
the tree. Now that we’ve cleaned things up, we’ll need to come up with
a different way for this to succeed.
Greg T. has an idea (posted earlier) to address this; unfortunately,
it’s too large of a change to make it into the stable branch until we
get thorough testing on the trunk. So release 3.03 will work as-is.
I beg to differ. It worked within the pkgsrc environment and only broke
in recent RC2.
Yes, it appears this was “accidentally” working before, as we were
allowing the system library paths to be included when building inside
the tree. Now that we’ve cleaned things up, we’ll need to come up with
a different way for this to succeed.
By my recollection it was the intent of having these switches to enable
developers to select and build individual modules.
Greg T. has an idea (posted earlier) to address this; unfortunately,
it’s too large of a change to make it into the stable branch until we
get thorough testing on the trunk. So release 3.03 will work as-is.
In this case I will base the pkgsrc collection on RC1 for now, which I
have
ready for commit.
It would be nice to see a solution for future releases.