search

paul-michalik / g2o

g2o: A General Framework for Graph Optimization
http://openslam.org/g2o.html
0 stars 0 forks source link

Support for g2o_viewer build is added. #10

Open PTavse opened 6 years ago

paul-michalik commented 6 years ago

Next time, please use the convention for naming of feature branches: feature/#<issue-Jira-or-GitHub>-title

paul-michalik commented 6 years ago

I must admit I do not particularly like this solution... It is too "unconventional". Have you tried to build a vcpkg port? I am just curious if one could create an out-of-source vcpkg port and inject it into user's %USERPRFILE%\.vcpkg folder...: mklink "%~d0..\..\ports\qglviewer" "%VCPKGROOT%\ports" @apattnaik0721013 Would vcpkg recognize it? I see no reason why it shouldn't. This way we could use the official repo with injected ports which we maintain separately...

paul-michalik commented 6 years ago

@PTavse It does not work for me. Whatever I do qmake libQGLViewer-2.7.1.pro -spec win32-msvc CONFIG+=Debug produces the following error:

Could not find qmake configuration file win32-msvc.
Error processing project file: libQGLViewer-2.7.1.pro

I hate Qt... I have tried everything except re-building qt5-base which I am doing now.

ras0219-msft commented 6 years ago

Note that the qmake.exe inside vcpkg is currently only meant for us to build other qt projects internally -- it won't work "out-of-the-box" to build other projects because you need to generate an appropriate qt.conf on demand[1] for your configuration.

Thus it will probably be easier to package QGLViewer as a port and use our helper vcpkg_configure_qmake() to deal with it.

[1] https://github.com/Microsoft/vcpkg/blob/7528c4d525419a418e8e0046f6650b833ad75fd7/scripts/cmake/vcpkg_configure_qmake.cmake#L33-L53

paul-michalik commented 6 years ago

Yeah, I was too optimistic... The qmake.exe in tools\qt5 seems partially functional. It finds all tools and builds the libs. It just puts everything into weird locations and I'm unable to figure out how to control it. So making a port is definitely a better choice...

PTavse commented 6 years ago

That's right. qmake.exe won't work out-of-box without proper configuration. I will try preparing vcpkg port for that.

paul-michalik commented 6 years ago

@PTavse Did it work for you in the first place? For me, I actually could use qmake and other Qt tools as proposed with few exceptions: The command line for qmake is qmake libQGLViewer-2.7.1.pro CONFIG-=debug CONFIG+=release for a Release build and qmake libQGLViewer-2.7.1.pro CONFIG-=release CONFIG+=debug for a Debug build (case sensitive). I haven't seen any influence of the -spec win32-msvc option, it is either completely controlled by the environment prepared via vcvarsall.bat or there is other magic involved. Please check how vcpkg sets the toolchain options (-spec) starting at the file referenced by @ras0219-msft There seems to be a pair of CMake template files qt_release.conf and qt_release.conf which are configured at proper locations whenever qmake is used, please check the content to see what we were doing wrong.

I was spending time on this in order to see if we can use the Qt tooling built via vcpkg install qt5-base for building "side-project", i.e. projects for which we do not have (or do not want) a vcpkg port. I guess it should work, this would be a question for @ras0219-msft: How is the Qt installation created by vcpkg special? The toolchain is complete, the environment is compatible so it should work. I'd like to consider the vcpkg Qt installation process a fully functional substitute for the official Qt installer... This would solve all the compatibility problems you usually run into when trying to use the official Qt binaries with other projects.

ras0219-msft commented 6 years ago

How is the Qt installation created by vcpkg special?

@paul-michalik Unfortunately, I don't completely know. I've only made sure our local "installation" works for:

So it's possible that they could be used externally, but I don't know enough about the qmake buildsystem to properly validate it one way or another.

Looking at the current scripts, here's how we internally build libraries:

  1. We always use qmake.exe from the current release installed directory.
  2. We configure <installed>/tools/qt5/qt_release.conf into a fresh directory to do a release build. This fills in Prefix = with the current installed directory (e.g. installed\x64-windows\).
  3. We run the qmake.exe from (1) with -qtconf path/to/qt.conf from (2)
  4. We add ${CURRENT_INSTALLED_DIR}/lib;${CURRENT_INSTALLED_DIR}/bin;${CURRENT_INSTALLED_DIR}/tools/qt5 to the path
  5. We run jom.exe qmake_all to generate Makefiles
  6. We then patch those makefiles to fix things like linking against the wrong zlib (zlib.lib instead of zlibd.lib) as well as adding lib\manual-link\ to the link directories and adding shell32.lib to the link line.
  7. We then run jom.exe to do the main build
  8. We find all generated cmake files in the intermediate directory and patch them up to be relocatable using fixcmake.py
  9. We patch up the makefiles again, but this time to redirect the install directory
  10. We finally run jom.exe install
  11. Repeat steps 2-10 for debug. We actually run them semi-concurrently, but they should be independent.

If it's possible to make things more externally useful, I'd be happy to accept PRs towards that goal!

paul-michalik commented 6 years ago

@ras0219-msft Ok, so qmake will remain a mystery until the next Steven Hawking emerges :-) I have had this struggle with other projects several times before and have always given up at some point.

@PTavse Assuming we want to try the "side-project" idea, I guess it would be simpler to write CMake script to build libqglviewer. From what I understand, this scenario should be fully supported by vcpkg provided machinery. All the automoc et. al. support via CMake should work (provided the toolchain file from vcpkg is loaded), so no reason to hassle with qmake. What do you think?