I'm trying to build gnuradio 3.7.9 on raspberry pi as the version provided by apt-get has some problems.
However the classic cmake/make/mke install procedure tries to build the documentation which requires latex to be installed. As don't want to install latex, I'm looking for an option to build gnuradio without the documentation.
Any help appreciated
Cmake will just disable documentation of it doesn't find doxygen. And if doxygen doesn't find LaTeX, it should just skip the formulas.
Anyway, use cmake with the -DENABLE_DOXYGEN=OFF flag.
More importantly, don't build GNU Radio on the pi itself. The raspberry pi is an embedded device, not a compilation platform, to be honest. RAM will quickly become a bottleneck, and together with the limited storage bandwidth that means that even if successful, the build will take days.
Instead, spend that time on fixing whatever is wrong with the packet. I do happen to know the maintainer of the Debian gnuradio packages, and he's a really nice guy. If you can write a good bug report, I'm sure he, or the GNU Radio mailing list, will figure something out.
Related
I have begun to use GTK(2), and I find that the workings of the library to be very good, but the documentation sucks.
I want to upgrade to GTK3, but it seems I need to install something called packman. That is a difficult philosophical step for me. Why can't I simply download a zip file(s) somewhere?
The documentation uses a lot of words without saying much, and the downloads want you to download stuff OTHER then gtk in order to get gtk. Why don't they simply have a GTK package and let me decide if I need all the other stuff.
Also, I have been reading on forums, even if I do the packman stuff, it still isn't enough for C::B.
Anyway, that is mostly a rant, what I'd really like is a suggestion to an alternative to GTK+.
Here are some of my requirements...
#1, It must NOT be an interpreter. Using Code::Blocks and C, I get an exe file and I'd like to continue that way.
#2 It must be programmable using C. I'd really like to stick wiith C::B, but I guess in a pinch I can use Eclipse (although that is another nightmare I won't get into here.)
#3 GTK requires a bunch of DLL's to be shipped along with the exe file. It would be ideal if the entire target could be included in the single exe without having to rely on external dll's or .net framework or other external stuff.
Any suggestions woule be apreaciated.
Thanks, Mark.
You best bet is to give a look at https://en.wikipedia.org/wiki/List_of_widget_toolkits#High-level_widget_toolkits
If you wan to stick to C and not C++, then Qt is out.
The other that stands out is EFL. I've never used it myself, but it has good reputation and probably your best bet if you want to quit GTK+ and stick to C. However I don't know how easy it is to use it on Windows.
Now about GTK+:
Also, I have been reading on forums, even if I do the packman stuff, it still isn't enough for C::B.
There are people here that use GTK+ with Code::Blocks, so I don't get what kind of problem you're referring to.
Then your other problems:
The documentation uses a lot of words without saying much
Examples?
the downloads want you to download stuff OTHER then gtk in order to get gtk
What you don't get is that GTK+ is more that just the libgtk library. It has dependencies on a lot of other libraries, like glib, cairo, pango, etc. In the past there used to be a bundle or installer to have that installed on Windows, but people would mess up on setting the environment up based on their needs and give up. As the GTK+ manpower for the Windows platform is limited, the GTK+ team delegated the distribution of the GTK+ binaries to the MSYS2 project.
MSYS2 is a popular project that provides a lot of open source software already built for Windows, and solves the problem of building and installing dependencies by hand for the user. This step is made to make installation simpler, not harder. In a handful of commands you have GTK+ and all its dependencies installed for your platform, and can start coding your app. Another command and you have python and the python GTK+ bindings installed and can get started. Want to depend on another popular library? Chances are MSYS already provides it.
Windows has been known for decades to be bad on dependency management. If package management wasn't a a pain point on Windows, then stuff like chocolatey or conan wouldn't exist.
Your philosophical reluctance is merely that: philosophical. Sure GTK+ on Windows isn't perfect. With MSYS2 you will get packages built with gcc so the debug symbols are not compatible with the Visual Studio debugger and you will need to use gdb instead. But on your other question you say you use gcc and loathe Visual Studio, so this should not be a blocker to you.
GTK requires a bunch of DLL's to be shipped along with the exe file. It would be ideal if the entire target could be included in the single exe without having to rely on external dll's or .net framework or other external stuff.
This is not possible for the moment as static compilation of GTK+ isn't supported. The redistribution of an app, however, isn't as easy as I'd like it to be. The best way on Windows to redistribute your app while using MSYS2 is to create a pacman package for your app, listing its dependencies, then call pacman to install your app on an empty directory and tell it to install all your dependencies there too. The result will be a directory that you can redistribute, with a self-contained installation of your app and all its dependencies, GTK+ included.
I need to install SUMO 0.30.0 to be used with the VEINS_INET subproject in veins 4.6. I have tried following the instructions here and suggestions from forums but haven't had any luck being able to install sumo. I run ./configure (trying various tool/library options) then run sudo make but all I get is target marouter failed or nothing to be done for 'install-exec-am' 'install-data-am'.
Does anyone know how to install sumo-0.30.0 from source and/or make the veins_inet subproject work with the latest version of sumo-0.32.0?
Don't run sudo make.
Don't run sudo make.
Your problem is probably related to a dependency/packaging change in 16.04, which is explicitly pointed out in the veins tutorial:
Note that Ubuntu 16.04 no longer includes libproj0; this can be worked around by temporarily adding the packet repository of, e.g., Ubuntu Vivid when installing this package.
Short answer: Unfortunately this means that long-term, you're going to either have to package SUMO yourself, use the versions someone else compiled (see this launchpad for example) or rely on an old version.
Long answer:
In general, I would recommend building SUMO from source by building its' dependencies from source, since I've encountered this problem on various distributions. In particular, the fox, proj and gdal libraries tend to be packaged in different versions, and along with changes in the SUMO source code. I currently use this script (with the package versions downloaded) to compile SUMO -- but this is for 0.30.0, and it breaks if any of the referenced source packages are moved (which happens quite often). My general recommendation would be to either use a completely isolated version of SUMO (i.e., compiling by hand as much as possible) or relying on a pre-packaged version (see above), as long as that version is recent enough to work with VEINS.
Today I noticed this fairly old (and highly voted) question and it made me wonder, if pip is generally preferred over easy_install in the Python community, why is the official ipython.org documentation instructing newcomers like me to use easy_install as shown here?
Perhaps there is an implicit assumption that readers are using Python 2? Although the highly voted question and several answers all seem to indicate that pip is widely preferred over easy_install for both py2 and py3, so that seems like it's not the answer...
The command:
easy_install ipython[zmq,qtconsole,notebook,test]
will install IPython and some dependencies, including pyzmq, which has compiled parts.
easy_install handles binary packages, so it can install precompiled versions of things like pyzmq. pip, by contrast, only works with source packages. So for a package with compiled parts, it downloads the source code and tries to compile it. There are two problems with that:
The user needs to have a C compiler installed, plus whatever development headers the code being compiled relies on. The user often doesn't.
It's slow, especially for larger packages.
So the scientific Python world, which uses a lot of compiled packages, doesn't use pip as much as web developers. Actually, we don't much like easy_install either - we have a variety of more powerful installation methods.
I need to install a perl tool on a production server which has no compiler. I can install CPAN distributions fine via local::lib, but the lack of compiler means I have to ask the sysadmins to install further modules. Due to them having an average turnaround time of 1-2 weeks even for the most ridiculously simple tasks, the process of trying to install, asking them to install what's borked, trying to install again, etc. etc. is extremely painful.
So how can i figure out quickly which given dependencies of a dist require a c compiler, so i can just give them a list?
When you search for a module in CPAN at http://search.cpan.org, take a look at the far right side of the browser window. Over there you'll see a link called Dependencies. This is right below the link to download the module.
If you click on that link, it'll take you to http://deps.cpantesters.org which will show you the dependency tree for that module. For example, take a look at this one for File::Spec at http://deps.cpantesters.org/?module=File::Spec&perl=5.12.1&os=any+OS&pureperl=on&devperls=on.
It's not perfect, but it'll give you a good idea what modules you do need.
The best way is to use the cpan command or the ppm manager on Windows. These will automatically download the dependent modules.
Maybe you could just install all you need on a test server and then package the application along with its dependencies using PAR?
As David said, cpantesters tries to figure out if a module is "pure"..
their explanation on how they do this might be helpful ..
Or I guess you could just install the modules on a similar system and copy them over? Or is this against the "rules"? ;)
Figured out a solution:
Trace system calls with Technet ProcMon (for Windows) or strace on Linux, then run the test suite and filter the result for "/auto/". That way you'll see all dlls it tries to load and can work out the dists requiring a compiler from there.
It seems that most of the installers for Perl are centered around installing Perl modules, not applications. Things like ExtUtils::MakeMaker and Module::Build are very well suited for modules, but require some additional work for Web Apps.
Ideally it would be nice to be able to do the following after checking out the source from the repository:
Have missing dependencies detected
Download and install dependencies from CPAN
Run a command to "Build" the source into a final state (perform any source parsing or configuration necessary for the local environment).
Run a command to install the built files into the appropriate locations. Not only the perl modules, but also things like template (.tt) files, and CGI scripts, JS and image files that should be web-accessible.
Make sure proper permissions are set on installed files (and SELinux context if necessary).
Right now we have a system based on Module::Build that does most of this. The work was done by done by my co-worker who was learning to use Module::Build at the time, and we'd like some advice on generalizing our solution, since it's fairly app-specific right now. In particular, our system requires us to install dependencies by hand (although it does detect them).
Is there any particular system you've used that's been particularly successful? Do you have to write an installer based on Module::Build or ExtUtils::MakeMaker that's particular to your application, or is something more general available?
EDIT: To answer brian's questions below:
We can log into the machines
We do not have root access to the machines
The machines are all (ostensibly) identical builds of RHEL5 with SELinux enabled
Currently, the people installing the machines are only programmers from our group, and our source is not available to the general public. However, it's conceivable our source could eventually be installed on someone else's machines in our organization, to be installed by their programmers or systems people.
We install by checking out from the repository, though we'd like to have the option of using a distributed archive (see above).
The answer suggesting RPM is definitely a good one. Using your system's package manager can definitely make your life easier. However, it might mean you also need to package up a bunch of other Perl modules.
You might also take a look at Shipwright. This is a Perl-based tool for packaging up an app and all its Perl module dependencies. It's early days yet, but it looks promising.
As far as installing dependencies, it wouldn't be hard to simply package up a bunch of tarballs and then have you Module::Build-based solution install them. You should take a look at pip, which makes installing a module from a tarball quite trivial. You could package this with your code base and simply call it from your own installer to handle the deps.
I question whether relying on CPAN is a good idea. The CPAN shell always fetches the latest version of a distro, rather than a specific version. If you're interested in ensuring repeatable installs, it's not the right tool.
What are your limitations for installing web apps? Can you log into the machine? Are all of the machines running the same thing? Are the people installing the web apps co-workers or random people from the general public? Are the people installing this sysadmins, programmers, web managers, or something else? Do you install by distributed an archive or checking out from source control?
For most of my stuff, which involves sysadmins familiar with Perl installing in control environments, I just use MakeMaker. It's easy to get it to do all the things you listed if you know a little about MakeMaker. If you want to know more about that, ask a another question. ;) Module::Build is just as easy, though, and the way to go if you don't already like using MakeMaker.
Module::Build would be a good way to go to handle lots of different situations if the people are moderately clueful about the command line and installing software. You'll have a lot of flexibility with Module::Build, but also a bit more work. And, the cpan tool (which comes with Perl), can install from the current directory and handle dependencies for you. Just tell it to install the current directory:
$ cpan .
If you only have to install on a single platorm, you'll probably have an easier time making a package in the native format. You could even have Module::Build make that package for you so the developers have the flexibility of Module::Build, but the installers have the ease of the native process. Sticking with Module::Build also means that you could create different packages for different platforms from a single build tool.
If the people installing the web application really have no idea about command lines, CPAN, and other things, you'll probably want to use a packager and installer that doesn't scare them or make them think about what is going on, and can accurately report problems to you automatically.
As Dave points out, using a real CPAN mirror always gets you the latest version of a module, but you can also make your own "fake" CPAN mirror with exactly the distributions you want and have the normal CPAN tools install from that. For our customers, we make "CPAN on a CD" (although thumb drives are good now too). With a simple "run me" script everything gets installed in exactly the versions they need. See, for instance, my Making my own CPAN talk if you're interested in that. Again, consider the audience when you think about that. It's not something you'd hand to the general public.
Good luck, :)
I'd recommend seriously considering a package system such as RPM to do this. Even if you're running on Windows I'd consider RPM and cygwin to do the installation. You could even set up a yum or apt repository to deliver the packages to remote systems.
If you're looking for a general installer for customers running any number of OSes and distros, then the problem becomes much harder.
Take a look at PAR.
Jonathan Rockway as a small section on using this with Catalyst in his book.