[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] minor bug
Re: [Discuss-gnuradio] minor bug
Mon, 29 Aug 2011 12:19:14 -0400
On Sun, Aug 28, 2011 at 6:09 PM, Dimitris Symeonidis <address@hidden> wrote:
> Tom, I tried some more to clean up the dependencies list on Ubuntu.
> I found a few dependencies that we were installing that don't seem to
> be needed. ./configure, make and make check pass without errors. Can
> you please confirm that in fact they are not necessary? Thanks!
> * guile and guile-1.8-dev
I think we removed the need for the guile dependency fairly recently,
but it's still required in the older releases of GNU Radio. As I
mentioned in my last email, the guile-dev is required for distcheck
and to access the Guile build system (it's an undocumented way of
making static flowgraphs in scheme instead of Python). It's not a
requirement for everyone, though.
> * python-opengl
> * pyqt4-dev-tools and qt4-dev-tools
> * libqwtplot3d-qt4-dev
I'm not sure if the opengl is really necessary or not. We can probably
get rid of it, but would have to make sure it doesn't impact older
systems/releases in some way. I don't know the specific requirements
for it to say for certain.
The QT dev tools are needed if you want to build any QT-based systems.
So while they might not be necessary to install GNU Radio, they are
necessary if you are doing anything with gr-qtgui. We could
potentially remove them as dependencies and put in proper checks and
warnings when people want to make anything in gr-qtgui.
The qwtplot3d requirements have been removed. But, again, it was
necessary with older releases, so it should be mentioned for those.
> What's more, there are a few dependencies that don't need to be stated
> explicitly, as they get pulled in automatically by other packages we
> * libpulse-dev (pulled in by libsdl1.2-dev)
> * sdcc-libraries (pulled in by sdcc)
> * libqt4-dev (pulled in by libqwt5-qt4-dev)
> * libqtcore4 (pulled in by python-qwt5-qt4)
Agreed that they don't need to be stated explicitly. But it's probably
a good thing that they are. First, things might change in how they are
pulled in. Not likely, but it's possible, and since we require them,
they should be listed. But some of these things are not "requirements"
for a working GNU Radio installation. Perhaps some of these should be
removed from the required list. We could have a "Required" dependency
list and "Recommended" dependency list.
> Finally, there are three dependencies of gr-qtgui that are not checked
> by ./configure (i.e. configure passes, but make fails):
> * libfontconfig1-dev
> * libxrender-dev
> * libxi-dev
That's definitely a potential problem and should be addressed.
So here's a few thoughts on this (Josh and Johnathan, please pay
attention here!). It's likely that we are going to move to using cmake
soon. I'm not really too interested in making any significant changes
to the build system or dependency list until we make the decision to
go with cmake or stay with autotools. When that happens, though,
here's what we need to thing about:
1. There are some dependencies that we require that we could probably
do without. The guile and guile-dev stuff needs to be looked into.
First, can we get rid of guile as a dependency? Can we fix the issue
of guile-dev in cmake?
2. Figure out if we need python-opengl or not
3. Remove requirements for QT dev tools but throw proper warnings
where they are needed after installation.
4. Fix the checks for the missing packages in qtgui.
5. Think about making a "recommended" dependency list so that fewer
dependency _have_ to be installed for a working system.
It's important to keep in mind that we still have older versions of
OSes and GNU Radio about that have different dependency requirements.
I think the webpage list should encompass the maximum possible overlap
for any given system. While we are trimming down some dependencies,
that's often very new (like just in the git repo code), so we can't
remove these dependencies from the list based on that.
I also don't want to get into a mode of separating the "git" version
from the "release" version of the software, nor even differences
between releases. That would start to get things way too cluttered, I
think, and right now, they are close enough that it's not too bad to
ask people to pull in all of them. If things diverge a lot, we can
rethink this policy.
On a desktop/laptop system, we have so much space these days and
Internet speeds are constantly increasing, so I don't think that
having more dependencies than are absolutely required is too much of a
burden. Those working with older or more limited systems, I hope are
also savvy enough with their systems to understand it and make their
own choices. This would be helped by separating into a "required" and
"recommended" list of dependencies (I say recommended as opposed to
optional because, while they are optional, it's highly recommended to
use them all).
Thanks for pointing all of this out, Dimitrios.
> Dimitrios Symeonidis
> "If you think you're too small to make a difference, try sleeping with
> a mosquito!" - Amnesty International
> On 28 August 2011 18:08, Dimitris Symeonidis <address@hidden> wrote:
>> On 27 August 2011 23:10, Tom Rondeau <address@hidden> wrote:
>>> On Fri, Aug 26, 2011 at 10:00 AM, Dimitris Symeonidis <address@hidden>
>>>> I noticed that the "docs" component passes the configuration tests
>>>> even without doxygen installed. This on Ubuntu 11.04, latest gnuradio
>>>> from git master.
>>> That might actually be on purpose, since there is more in the docs
>>> than just the Doxygen-generated stuff. Does this generate and failures
>>> during make, make check, or make distcheck for you?
>> No, no errors in make && make check.
>> Make distcheck gives me an (irrelevant) error in gnuradio-core/src/lib/swig:
>> *** No rule to make target `guile/gnuradio_core_filter.cc', needed by
>> `distdir'. Stop.
>> Is this just me?
>>>> Also, it seems fort77 is no longer a dependency, not sure when it went
>>> Yeah, I don't recall why we had fort77 as a dependency. If it really
>>> isn't necessary, it shouldn't be listed.
>> This used to be required in order for ./configure to check for the
>> existence of the python headers (python-dev), or else ./configure
>> would claim that Python.h is missing.
>> Here's what I blogged almost exactly 2 years ago about this:
>>>> Have a nice weekend
>>>> Dimitrios Symeonidis
>>>> "If you think you're too small to make a difference, try sleeping with
>>>> a mosquito!" - Amnesty International
>>>> Discuss-gnuradio mailing list
>> Dimitrios Symeonidis
>> "If you think you're too small to make a difference, try sleeping with
>> a mosquito!" - Amnesty International