Error generating .sln with CMAKE

I am following the instruction in:

When i click the genrete buttun i get the following log of errors:

cmake version: 3.18.0
Selecting Windows SDK version 10.0.14393.0 to target Windows 10.0.18362.
CMake Warning at CMakeLists.txt:127 (message):
  IPv6 is not available in your system.

Looking for libusb-1.0 : Found
Could NOT find Git (missing: GIT_EXECUTABLE) 
Looking for libserialport : Failed; building without serial
Building with Network back end support
Building with mdns, A Public domain mDNS/DNS-SD library in C 
Configuring done
CMake Error at tests/CMakeLists.txt:38 (add_executable):
  Cannot find source file:


  Tried extensions .c .C .c++ .cc .cpp .cxx .cu .m .M .mm .h .hh .h++ .hm
  .hpp .hxx .in .txx

CMake Error at tests/CMakeLists.txt:38 (add_executable):
  No SOURCES given to target: iio_writedev

CMake Error at tests/CMakeLists.txt:33 (add_executable):
  No SOURCES given to target: iio_genxml

CMake Error at tests/CMakeLists.txt:37 (add_executable):
  No SOURCES given to target: iio_reg

CMake Error at tests/CMakeLists.txt:34 (add_executable):
  No SOURCES given to target: iio_info

CMake Error at tests/CMakeLists.txt:35 (add_executable):
  No SOURCES given to target: iio_attr

CMake Error at tests/CMakeLists.txt:36 (add_executable):
  No SOURCES given to target: iio_readdev

Any clue?


It is my first time writing to an embedded linux, I have C experience and already tried the matlab api)

  • 0
    •  Analog Employees 
    on Jul 17, 2020 5:16 PM 6 months ago

    You are missing a number of dependencies which CMake should list in the GUI.

    You should not have to build libiio unless you have a very specific reason. If you are just writing applications that use libiio you do not have to build it but just use the pre-compiled libraries:


  • I really don't understand

    When i point the SRC lib to the example library it fails at the configure stage

    The missing dependencies are not mentioned in the wiki guide&I have no clue where to find them

    Is there any tutorial i can just follow for the first couple attempts?

  • 0
    •  Analog Employees 
    on Jul 17, 2020 5:28 PM 6 months ago in reply to et.l

    Why are you building libiio? Do you need to modify libiio source? or are you just linking against it for your application?


  • I am much behind everything you said.

    Right now I have a twisted notion about how everything is connected, I understood that the libiio is the required input to CMAKE.

    All i try to do is to make a first successful compilation, and to manage to load it to PLUTO. Once it will happen - i guess ill have a better working point to continue to the my real goal 

  • +1
    •  Analog Employees 
    on Jul 17, 2020 5:53 PM 6 months ago in reply to et.l

    Maybe I can explain how things are connected and a recommended path to get started.

    Controlling the transceiver inside PlutoSDR is done through the library libiio. Like other libraries you simply need to link against it and include its header to use its functions. Please ignore the page about building libiio on Windows with CMake. That is about building the library and not writing applications that use it.

    The library allows you to connect to Pluto over USB remotely and control the device. When using libiio to talk to remote hardware you have to tell the library you want to talk to a remote context. This is the same at the DeviceID in MATLAB or the URI in python. There are helpers in those tools to automatically determine the context but not in C. This is the API you use to create contexts which other function calls will use to control the device:

    I would not recommend using the C API since you need to know more about the API itself and the driver which controls PlutoSDR. Stick with MATLAB or Python as they remove a lot of this complexity and are more forgiving during development.

    Now if you want to write applications to run on PlutoSDR itself this is a bit more complex since you need to compile everything for the ARM architecture, which requires linking against libraries built for ARM as well. Your C application can basically stay the same you just need to tell it to use a local context and not a remote one. We have an article that describes how to do this from Linux:

    We do not have a guide for Windows and for now, you would have to figure out how to do that on your own.