#2 Add support for a custom installation layout

VirtualGL (4)

The attached path adds some new cmake options:
- VGL_INCLUDEDIR - headers go in here (default: $CMAKE_INSTALL_PREFIX/include)
- VGL_LIBDIR - libraries go in here (default: $CMAKE_INSTALL_PREFIX/lib)
- VGL_FAKELIBDIR - the fake libGL library goes in here (default $CMAKE_INSTALL_PREFIX/fakelib for 32-bit or with /64 appended for 64-bit)

CMakeLists.txt contains the above new options and the below changes have been applied:
- The definition of "64BIT" has been moved up to allow DEFAULT_VGL_FAKELIBDIR be $CMAKE_INSTALL_PREFIX/fakelib/64 on 64-bit systems

rr/vglconnect is patched to use the bindir as given at installation time. This adds a new restriction to the length of the VGL_BINDIR (= $CMAKE_INSTALL_PREFIX/bin) which can be no longer than 245 characters.

rr/CMakeLists.txt has been updated to comply with notable changes below:
- rr/fakerconfig.h is created from rr/fakerconfig.h.in; this allows for a custom vglconfig location
- a definition of FAKELIBDIR has been removed, this is superseded by VGL_FAKELIBDIR
- a conditional creation of the fakelib directory and libGL.so symlink has been converted to two single commands because 32/64 bit is determined at the definition of VGL_FAKELIBDIR. The symlink from libGL.so to librrfaker.so is now absolute (previous it was a relative one with ../../lib/librrfaker.so)
- vglconnect is created from vglconnect.in which allows for a custom bindir location
- some changes in the vglconnect generation code was needed to allow for an out-source build with a read-only source directory

- rr/vglconnect must be renamed to rr/vglconnect.in
- rr/fakeconfig.h must be renamed to rr/fakeconfig.h.in

**all changes are backwards compatible, the default paths have not been changed**

The command that can be used for generating an installation layout that is used by official .deb packages is:

cmake -G "Unix Makefiles" -DTJPEG_LIBRARY=/usr/lib/libturbojpeg.a -DCMAKE_INSTALL_PREFIX=/usr -DVGL_FAKELIBDIR=/usr/lib/virtualgl/fakelib/64 -DVGL_DOCDIR=/usr/share/doc/virtualgl -DVGL_INCLUDEDIR=/usr/include -DVGL_LIBDIR=/usr/lib -DVGL_BINDIR=/usr/bin

I'll use that for VirtualGL as used in the Bumblebee project (https://launchpad.net/~mj-casalogic/+archive/bumblebee/+packages and https://github.com/MrMEEE/bumblebee\)

Related bug report: https://sourceforge.net/tracker/?func=detail&atid=678330&aid=3377271&group_id=117509


  • Lekensteyn

    Lekensteyn - 2011-07-27


  • Lekensteyn

    Lekensteyn - 2011-07-27

    Note: as I'm not familiar with Solaris (SunOS?), I've not touched those parts in vglrun. The configuration paths in /etc/opt/VirtualGL are not modified either.
    I don't see any reason for a custom installation path on windows, so that's neither supported by my changes.

    I could think of another change in the documentation: replace lines like /opt/VirtualGL/bin with @DOC_BIN_NIX@ and ensure that this path is set correctly (/opt/VirtualGL/bin on Win32 systems, VGL_BINDIR on *nix systems)

  • DRC

    DRC - 2011-07-27

    I don't have an issue with providing VGL_INCLUDEDIR, VGL_FAKELIBDIR, and VGL_LIBDIR as you've done (I was working on that in parallel, in fact.) However, I do have an issue with VirtualGL being packaged in a directory other than /opt/VirtualGL unless appropriate symlinks are provided in /opt/VirtualGL. Otherwise, I'm going to get support inquiries asking why these custom versions don't work as described in the VirtualGL User's Guide. For instance, people who try to use your version with Chromium couldn't use the procedure in the docs, because the docs specify that the fakelib path is /opt/VirtualGL/fakelib.

    What we're dealing with here is conflicting standards. I understand that O/S distributions like things in a certain place, but VirtualGL also likes things in a certain place. We're a cross-platform client/server toolkit, so we have to consider both the needs of the client and the server on various platforms. On Solaris, for instance, it's forbidden to package anything under /usr. The client needs to know that it can find things in a specific place on the server, and the place we chose many years ago is /opt/VirtualGL, because that location works for all supported server platforms.

    vglconnect is used to connect to any VirtualGL server, not just the ones that use your specific packages. Thus, vglconnect can't assume that the VirtualGL scripts are installed in a custom directory on the server. It must assume that they are installed (or symlinked) in /opt/VirtualGL. Any server that doesn't do that is breaking compatibility with VirtualGL clients. You have to also remember that a Windows machine can be used as a VirtualGL client, and vglconnect.bat also expects to find the scripts in /opt/VirtualGL on the server.

    In general, what I'd like to do is implement VGL_LIBDIR, VGL_FAKELIBDIR, and VGL_INCLUDEDIR as you have suggested and then have the install system automatically create symlinks to these under CMAKE_INSTALL_PREFIX if necessary (but symlink creation could be disabled with an additional flag.) Changing the default path in vglconnect is unacceptable, due to reasons cited above. I object less to the fakerconfig change, but I also think it's unnecessary, as your packaging needs to be creating a symlink from /opt/VirtualGL/bin/vglconfig -> /usr/bin/vglconfig anyhow.

  • Lekensteyn

    Lekensteyn - 2011-07-27

    Okay, I understand your point that /opt/VirtualGL must exist for historical reasons. Would it be possible to specify an option to install files to /usr/bin, while creating symlinks in /opt/VirtualGL then? It's especially needed for the binaries so /opt/VirtualGL/bin does not have to be added to $PATH.

    Please ignore my change regarding @VGL_BINDIR@ in vglconnect, it is inconsistently implemented by me because VGL_BINDIR != VGL_BINDIR on server.

    As for the change in fakerconfig, Martin Juhls virtualgl build already violates it because he's not aware of the dependency. Please allow for custom builds that do not expect such fixed paths and in which /opt/VirtualGL can consist of symlinks only which are not necessarily needed to let VirtualGL work.

    VirtualGL as used by Bumblebee targets home users, I believe that you are targeting business users?

  • DRC

    DRC - 2011-07-27

    The reasons why VirtualGL puts things where it does are deeper than purely "historical reasons." There are technical reasons as well. For instance, on Linux, we package the vgl* executables and scripts in /usr/bin so the user doesn't have to add /opt/VirtualGL/bin to their PATH, but everything else is packaged under /opt/VirtualGL/bin. This is, as much as anything, to avoid the possibility of a conflict with some other package. /usr/bin/glxinfo, in particular, exists in other packages.

    I'm starting to have second thoughts about providing the level of customization proposed by this patch. The reasons are philosophical-- at some point, I have to raise the question of whether cluttering up the build system is appropriate or whether this type of customization is really the job of the packager. It also creates a support burden.

    I'd have less of a problem with it if our own packaging system could leverage it, because that means that the functionality would be automatically tested every time we built our own packages. However, the way we package things doesn't fit cleanly into this paradigm.

    VirtualGL is not like most open source projects. It works more like a product. We provide specific binary packages that we support, and we expect that most users will use the binary packages that we provide. Bumblebee is doing something very specific for a specific platform. We cannot make special accommodations for what they are doing, as it has really nothing to do with the overall purpose of The VirtualGL Project (remote 3D.) If Martin is breaking compatibility with VirtualGL, then that's a problem that needs to be addressed with Martin.

    I don't get paid a salary to maintain VirtualGL, so unless there is specific sponsorship of a proposed feature, I will mostly be looking for solutions that create the least amount of maintenance burden for me.

    Let me think more on this.

  • DRC

    DRC - 2011-07-27

    After thinking about this further, I think I am OK with implementing VGL_BINDIR, VGL_DOCDIR, VGL_INCDIR, and VGL_LIBDIR, with some stipulations. VGL_FAKELIBDIR is, in my opinion, a useless option. The libGL symlinks need to be under /opt/VirtualGL/fakelib, because that is where they are documented. Putting them elsewhere serves no purpose.

    Additionally, I believe that only the vgl* scripts and executables should reside in VGL_BINDIR and all other executables (tcbench, nettest, glxspheres, glxinfo, cpustat should continue to reside in ${CMAKE_INSTALL_PREFIX}/bin. This will allow me to utilize the new VGL_*DIR variables when generating our own packages.

    Also, the build system will automatically create the appropriate symlinks under ${CMAKE_INSTALL_PREFIX}, and it will warn the user if CMAKE_INSTALL_PREFIX != /opt/VirtualGL.

    If all of that is acceptable, I will proceed with implementing it.

  • DRC

    DRC - 2011-07-27

    Disregard previous message. Upon further thought, I think it's best to just implement the options as you have suggested and not try to second guess the user. There will just have to be an understanding that, if the packager chooses to install in a directory other than /opt/VirtualGL and not provide symlinks, everything will still work, but:

    (a) The paths in the documentation won't match. Your suggestion about dynamically generating these paths might be viable if we were using a different doc system, but currently we use Deplate because it's the easiest system to use that provides the necessary features we need in the documentation (I'd love to use RST, but it just isn't there yet with the feature set.) Since Deplate isn't provided with any O/S distributions and requires Ruby, it isn't something I want to require everyone to have before they can build VGL. Thus, auto-generating the docs isn't something that can be done right now. Maybe in the future.

    (b) If a client uses vglconnect -s or vglconnect -x to connect to a VGL server that doesn't provide /opt/VirtualGL/bin/vgllogin, the client will need to additionally specify -b with the path (such as /usr/bin) under which the server can find vgllogin. vglconnect -x and vglconnect -s are used rarely enough that this shouldn't be a huge limitation.

    CVS HEAD should contain the new implementation. Please test it.

  • DRC

    DRC - 2011-07-27
    • status: open --> closed-fixed
  • Lekensteyn

    Lekensteyn - 2011-07-27

    About a) You could use cmake's configure_file to allow for quick subsitution of the paths. It might not be the cleanest option, but it works.

    b) as with the use case Bumblebee, indeed, those options will never be used for that. If the server admin decided not to install VGL to /opt, (s)he would notify their users, right?

    Thank you, I've tested it with my desired layout, and it works:

    cmake -G "Unix Makefiles" -DTJPEG_LIBRARY=/usr/lib/libturbojpeg.a -DCMAKE_INSTALL_PREFIX=/usr -DVGL_FAKELIBDIR=/usr/lib/virtualgl/fakelib/64 -DVGL_DOCDIR=/usr/share/doc/virtualgl -DVGL_INCDIR=/usr/include -DVGL_LIBDIR=/usr/lib -DVGL_BINDIR=/usr/bin ../src

    (I did an in-source build as well, and it works fine too)

    To be sure that paths were working properly, I tried the next as well:

    cmake -G "Unix Makefiles" -DTJPEG_LIBRARY=/usr/lib/libturbojpeg.a -DCMAKE_INSTALL_PREFIX=/nowhere -DVGL_FAKELIBDIR=/fake64 -DVGL_DOCDIR=/docs/virtualgl -DVGL_INCDIR=/includes -DVGL_LIBDIR=/libs -DVGL_BINDIR=/bins src

    I installed it with make install DESTDIR=tmp

    If we package virtualgl for Bumblebee, would you like us to put something in the version number or description regarding the non-default change? Of course, we could write a patch that modifies the paths in the documentation, or even add a notice about the unofficial virtualgl build.

    Thanks for efforts, it is much appreciated.


  • Lekensteyn

    Lekensteyn - 2011-07-27
    • status: closed-fixed --> open
  • DRC

    DRC - 2011-07-27
    • status: open --> closed-fixed
  • DRC

    DRC - 2011-07-27

    I think your best bet is probably to patch the documentation. As far as using configure_file, upon further thought, it might be possible to do that with index.html and not require a rebuild of the documentation (in other words, @VGL_BINDIR@, etc. is simply part of the HTML file.) However, there are still two show-stoppers:

    (a) The documentation must describe paths for both 64-bit and 32-bit builds in several places.

    (b) The documentation needs to be human readable in CVS, so I can link to the evolving version of it (http://www.virtualgl.org/Documentation/Documentation)

  • DRC

    DRC - 2011-12-17
    • assigned_to: nobody --> dcommander
  • DRC

    DRC - 2011-12-17
    • labels: --> VirtualGL
  • DRC

    DRC - 2014-08-05
    • Status: closed-fixed --> closed-integrated

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks