libonvif icon indicating copy to clipboard operation
libonvif copied to clipboard

Python-less Build

Open pele1410 opened this issue 6 months ago • 6 comments

https://github.com/sr99622/libonvif/pull/57 added the ability to set the WITHOUT_PYTHON flag to build only the libonvif and onvif-util (C/C++ code). This was removed in a recent update but it is still desirable as I run the libonvif on a headless server.

Is there still a way to accomplish this? If not, I'm happy to work on a solution that does just that.

pele1410 avatar Jul 01 '25 12:07 pele1410

My current workaround is to just compile the onvif-util directory with this colcon command

colcon build --packages-skip-regex="(?=.*onvif.*)(?!onvif-util)"

(Simplified from my actual command)

pele1410 avatar Jul 01 '25 12:07 pele1410

Actually, this won't really work for me. I need the libonvif as a .so I can link against in my application and not as a static lib in onvif-util.

pele1410 avatar Jul 01 '25 13:07 pele1410

I can see where having the .so library can be useful, I was not really aware that it was missing. At some point it used to be there, but I don't use it myself, so it got lost in the shuffle. You can generate this pretty easily from the onvif-util build, you just need to add the SHARED tag into the add_library of the CMakeLists.txt file for onvif-util. Once this is in place the libonvif.so file will be generated when you make the onvif-util program. I will add this into the project in the next upload coming soon. The change to libonvif/onvif-util/CMakeLists.txt is shown below, just add SHARED after STATIC in the add_library clause

add_library(libonvif STATIC SHARED
    ../libonvif/src/onvif.c
    ../libonvif/src/cencode.c
    ../libonvif/src/sha1.c
)

sr99622 avatar Jul 02 '25 12:07 sr99622

Yeah I have a workaround that is generating it. It's good enough to keep me working while it's fixed properly.

I'd suggest that not requiring me to build the util would be better. While I do build the util program; it shouldn't really be a requirement to get the libonvif.so in my opinion.

pele1410 avatar Jul 07 '25 10:07 pele1410

I'm not sure your workaround is sufficient though, the headers need to be installed still.

pele1410 avatar Jul 13 '25 11:07 pele1410

This is true. In the current state, the library is pretty much a roll your own kind of deal. There is certainly room for improvement.

Maybe what we could do is to make a CMakeLists.txt file that would go into the top level project directory that would build the library static and dynamic versions and optionally create the onvif-util program. There could be an install clause in the CMakeLists.txt to specify where to put the headers and libraries. This way, somebody coming to the project for just libonvif would see the CMakeLists.txt in the main folder and be able to build the important pieces without having to fish through all the subdirectories.

The CMakeLists.txt would be pretty much the same as the one for onvif-util with the locations adjusted for the new position. The install clause would look something like

install(TARGETS onvif-util libonvif
RUNTIME DESTINATION bin
LIBRARY DESTINATION lib
ARCHIVE DESTINATION lib/static
COMPONENT Runtime
)

install(DIRECTORY libonvif/include/
DESTINATION include/libonvif
FILES_MATCHING PATTERN "*.h"
COMPONENT Development
)

Then the procedure would be

mkdir build && cd build
cmake ..
make 
make install

sr99622 avatar Jul 13 '25 14:07 sr99622