search

jakobwilm / slstudio

SLStudio -- Real Time Structured Light. A comprehensive software suite for capturing and reconstructing 3D scenes with a camera-projector pair.
Other
515 stars 194 forks source link

Further work on CMake build system, fix Visual Studio 2010 #3

Closed uboot closed 1 year ago

uboot commented 8 years ago

This is basically an extension of #1. The additions to #1:

To my knowledge this is one of very few serious open source implementations of structured light scanning and I hope I can find time to decouple the implementation of the scanning code from the presentation layer (=Qt + VTK). As I commented earlier I think porting to CMake makes sense for this task.

jakobwilm commented 5 years ago

I'd like to use many of the changes and functionality added. However, the project is qmake based and I don't see compelling reason to change that. Any good arguments?

hcw70 commented 5 years ago

The major argument is you are mentioning concrete versions of additional libraries like opencv, vtk et al. When i compiled your version, i needed to change some of those version specifiers to match my installation (Ubuntu 18.04).

With CMake you can (more or less) issue a "FindLibrary" and specify the minimum required library to use. So your build definitions become more portable, since most people wont need to fiddle within your qmakefiles any more since the version adaption happens automatically.

QtCreator can cope also with CMake based builds.

CMake is also well-documented, widely used and (most of the time) works flawesly...

hcw70 commented 5 years ago

See also https://stackoverflow.com/questions/34370088/what-are-the-differences-and-similarities-between-cmake-and-qmake . Im especially with https://stackoverflow.com/a/37457751 which shows a short example how to build QT5 projects with CMake.

QtProject itself thinks about switching to CMake: https://wiki.qt.io/Qt_build_systems_at_QtCon_2016

How to use CMake with QtCreator : http://doc.qt.io/qtcreator/creator-project-cmake.html

jakobwilm commented 5 years ago

Well, broader library support and more people knowing about CMake speak for it. However, it has some downsides, namely much worse integration into QtCreator and a very convoluted syntax. Looking at the different CMakeList.txt stuff in the PRs, it also seems to me that maintainability suffers. From personal experience, I also rather change a few lines of a .pro file than debug a failing CMake build based on cryptic output. So what it comes down to to me is whether there is a critical usecase which qmake simply cannot cover.

/Jakob

hcw70 commented 5 years ago

@jakobwilm The critical use case here is to gain more easy compilation in different environments (Win32 / WIn64, Ubunutu 14, Ubuntu 16, Ubuntu 18, MacOS, ...) which mainly differ in the versions of required additional libraries and the presence of optional libraries.

A good build system should figure out these things by itself.

So most non-expert users are not able to fix these kind of errors by himself and are distracted from your project.

If I download a project to try it, and compile it according to documentation, and it does not compile, i tend to delete it immediately if the most obvious fixes to the build dont help. And i am a "expert" user so to say, but the energy to put in to evaluate a SW whether it is worth to invest more energy should be as low as possible.

So if you want to enlarge the community of users of your SW (and i think you should, since it may become a good tool) you should at least:

I personally would like to use SLStudio since i would scan some stuff and use that in blender (faces, nature objects etc). What currently blocks me is:

hcw70 commented 5 years ago

@jakobwilm I had also a look into the given CMakeFiles in this PR.

To me they look good, since they let the user decide which option to have during builds and (to my knowledge) rely on the usual CMake usages to find the needed libs and stuff. That is not really reflected in the current QMakefiles, and so increases portability and maintainability.

The other changes in the PR i cant comment since i dunno the reaon (i.e. why some apis were changed from QSting -> std::string)...

uboot commented 5 years ago

The other changes in the PR i cant comment since i dunno the reaon (i.e. why some apis were changed from QSting -> std::string)...

This was a while ago but I am pretty sure that the original idea was to make the algorithmic core components (slalgorithm?) independent of Qt. As it seems that only minor changes were necessary to achieve this I think this still makes sense.