search

AlbrechtL / welle.io

A DAB/DAB+ Software Defined Radio (SDR)
https://www.welle.io
Other
625 stars 117 forks source link

Meson or CMake build? #50

Closed russel closed 7 years ago

russel commented 7 years ago

Is using QtCreator the only way of building this? It seems so currently, the CMake build has gone. Perhaps create a Meson build? Having a way of creating this out of tree, from a command line, without the development environment is a must.

AlbrechtL commented 7 years ago

Instead of using QtCreator you can also use qmake direct from the command line. See .travis.yml line 28 for an example.

I removed the CMake files because there aren't maintained since the dab-rpi fork and not working anymore. If you would like to maintain it - great! See the commits before e99aac0 to recover the CMake files.

I'm definitely open to a convenience way compile welle.io on the command line. The build system doesn't matter. You can use CMake, Meson or xyz. The only requirement that I have is that it will be well documented (how to build it, how to set up an build environment, etc, etc.) and that somebody maintains it and gives support.

Do you are willing to do that? Welcome to the welle.io development!

russel commented 7 years ago

Are you assuming that welle.io will be the replacement for DABlin or are you thinking there are two interfaces here. Currently I like the DABlin UI as it is harmonious with GNOME, however dab2eti needs a serious rewrite (which I am sort of committed to doing), because it really isn't very good. Qt_DAB has, for me, a dreadful UI, but actually works, so it is that that I currently use.

If I am to maintain only the build I will do Meson since it is seriously nicer than any other build system currently. If I am to get involved in the code then I'll have to do a CMake build since CLion currently only supports CMake.

I have only ever done PyQt5 before I have never done Qt from C++. Debian has Qt5 5.7, but Fedora has Qt 5.8. And I have never used QtCreator.

AlbrechtL commented 7 years ago

Are you assuming that welle.io will be the replacement for DABlin or are you thinking there are two interfaces here.

Difficult question. I started the interface as an easy to use interface for dab-rpi (Qt-DAB now). Since Jan (author of Qt-DAB) and I separated welle.io is a stand-alone project. For me the main target group are regular users. So a totally simple GUI is needed including a station scan. Because many computers are touch computers I decided to focus on a touch friendly interface. Please watch this video to see how to control welle.io via a touch display. However, DABlin isn't touch optimized and like Qt-DAB you have to know a lot about DAB to use the programs.

I think regular users don't care about the used libraries. They just use the installer, AppImage, etc, to install it and use it. I also think the community highly need an usable open source DAB/DAB+ SDR software and welle.io would like to be it (Europe is switching from FM to DAB+ and needs this software).

I asked also the author of DABlin for a collaboration but he didn't seems to be interested.

If I am to maintain only the build I will do Meson since it is seriously nicer than any other build system currently. If I am to get involved in the code then I'll have to do a CMake build since CLion currently only supports CMake.

The whole back-end needs a rewrite, especially the OFDM demodulate part. For the DAB frame decoding the DABlin code can be integrated. The challenged would be get the new code multi-threaded with a high performance. At the moment, welle.io used four threads for the main computation and is able to run even on the Raspberry Pi 2/3 and cheap Intel Cherry Trail CPUs.

I think it is up to you to choose your development IDE. If you need CMake to use CLion, fine. I would be happy to get you on board!

russel commented 7 years ago

Now a work in progress. I have made a cmake-reinstall branch (which I will update to GitHub) and when I have something workable, I'll send in a pull request.

russel commented 7 years ago

I have created a CMakeLists.txt with a few files in the directory cmake, and it compiles all the files to objects. Currently though link is failing with:

CMakeFiles/welle-io.dir/src/backend/audio/mp4processor.cpp.o: In function `faadDecoder::faadDecoder(CRadioController*, RingBuffer<short>*)':
/home/russel/Repositories/Git/Forks/WelleIo/src/backend/audio/faad-decoder.h:50: undefined reference to `vtable for faadDecoder'
CMakeFiles/welle-io.dir/src/backend/audio/mp4processor.cpp.o: In function `faadDecoder::~faadDecoder()':
/home/russel/Repositories/Git/Forks/WelleIo/src/backend/audio/faad-decoder.h:61: undefined reference to `vtable for faadDecoder'
CMakeFiles/welle-io.dir/src/backend/audio/mp4processor.cpp.o: In function `faadDecoder::MP42PCM(unsigned char, unsigned char, short, unsigned char, unsigned char*, short)':
/home/russel/Repositories/Git/Forks/WelleIo/src/backend/audio/faad-decoder.h:163: undefined reference to `faadDecoder::newAudio(int)'
/home/russel/Repositories/Git/Forks/WelleIo/src/backend/audio/faad-decoder.h:175: undefined reference to `faadDecoder::newAudio(int)'

which I haven't sussed out as yet. I suspect this is still only a beginning as there is no Airspy, rtlsdr, or SoapySDR stuff.

https://github.com/russel/welle.io/tree/cmake-reintroduction

AlbrechtL commented 7 years ago

The faad library is not linked to the binary. Please look into the old CMakeLists.txt to see how to link it to the binary.

russel commented 7 years ago

That CMake file is the one I was using to drive the current file (along with welle.io.pro). faad is treated as just another library. and that is what I have. Clearly I am just missing something.

AlbrechtL commented 7 years ago

I added the libfaad direct to the source for the Android support . If you like you can use it to workaround your issue. Look into the welle.io.pro line 208 how to use it.

russel commented 7 years ago

Hummm… Is it likely you will amend the Faad2 source, is it to become an Android specific version?

If this is just vendoring of Faad2, I can certainly amend to use it, but I am not sure this solves the problem. I am not sure what the Qt build was/is doing to avoid the problem, which is really about there not being a concrete instance of a type that is being used in the Welle.Io code.

I have to go to be the chair of the ACCU conference this week, so won't have time to look at this till after that, and then there is DevoxxUK so it may be three or four weeks before I can get back to this. Apologies in advance for the delay.

AlbrechtL commented 7 years ago

Hummm… Is it likely you will amend the Faad2 source, is it to become an Android specific version?

No. It compiles also on Linux. But I think I will only use it for Android because the libfaad version of the Linux distributions should be newer and I'm not really interested in maintaining the libfaad code.

... which is really about there not being a concrete instance of a type that is being used in the Welle.Io code.

undefined reference to 'faadDecoder::newAudio(int)': Mhh, newAudio is a signal. Maybe something went wrong with qmake?

russel commented 7 years ago

It is something wrong with the Qt preprocessing I now realise. I will have to research, I had assumed the CMake tooling had handled things, but apparently not.

russel commented 7 years ago

It seems that the Welle.Io source is somehow incompatible with the CMake AutoMOC processing. All the files the CMake documentation claim to be present are, yet this is not sufficient for a successful build. This is now getting annoying.

russel commented 7 years ago

It seems that the above hypothesis is correct the AUTOMOC search is finding most but not all the files with a Q_OBJECT. This should be fixable now it is known what the actual problem is. I'll close this issue now, as a WIP and submit a pull request when I have something working.

AlbrechtL commented 7 years ago

I didn't expect that it is so difficult to get cmake working again. Good luck!