Creating an automated build system

[Nick Cannon]

There has been a steadily increasing demand for some form of automated build system for the VFX Reference Platform, for Windows and macOS in addition to Linux.

Such a system would provide an easier entry-point to building against the VFX Reference Platform as well as a more detailed specification for often requested information such as compiler flags and precise versions.

We are now starting work to coordinate a community effort to create such a system and have it validated by studios and vendors.

A handful of people across the industry have already offered to contribute to such an effort but we are looking for a few more. If you have relevant build engineering experience, particularly on macOS or Windows, and are willing to make a commitment to contributing then please email volu...@vfxplatform.com.

We are also seeking suggestions and opinions on what form such a system would take and what its scope should and should not include. Please share either by replying to this thread or privately to feed...@vfxplatform.com.

Thanks

Nick

[Chad Dombrova]

I suggest using rez as a starting point. We’ve created a custom build plugin for rez which adds functionality much like homebrew: it can retrieve source code from repos (git or hg) or archives (zip, tar, tar.gz, etc) living locally or remotely, and then run a series of build commands, before handing the result back to rez to finalize the release. It wouldn’t take much work to make it recursively build dependencies.

Rez is a good starting point for the following reasons:

• it’s used widely in the VFX and animation industries
• it already solves the problem of specifying dependencies (and whether or not they are build or runtime dependencies), managing variants, and setting up working environments. anyone who has work with the rez source knows this stuff is not trivial to get right.
• it’s pluggable enough to add the type of functionality that you’re after
• it’s actively maintained
• this functionality is something that most rez users would want, so you’re likely to find plenty of eager contributors (the pro and con here is of course that you’ll have lots of opinions to mediate).
  We’d be glad to provide the source to our plugin as a starting point. We went with a declarative approach (yaml configuration file), but in hindsight I’d would recommend exploring an imperative approach, because I think this would be more flexible, easier to grok, and should work nicely with “rex”, rez’s pluggable python command execution environment. That said, there are still benefits to the declarative approach, and either way the source to our plugin would be useful, should you decide to go with rez as a starting point.

-chad

​

[Allan Johns]

Thanks for the info Chad.

I'd just like to add that I'm interested in recursive builds and I can see a way to do that. I think with some work it's certainly possible to get to a point where a "rez-install X" command will read from a local package repository (in much the same way as apt) and perform all relevant builds/releases.

I'm actually just about to release a feature that solves another problem related to this. The issue currently is that a package definition file just specifies its requirements as hardcoded values - for example, your package may require "boost-1.55.0". The problem is that while your compiled lib may need that specific version at runtime, it may actually be compatible with a wider range of boost versions at build time - but there isn't a way to describe that in the package definition currently. Until now. I'll leave the details for the imminent rez release, but that's one more barrier removed to rez being a bit more of a grown up deployment tool.

Thanks

Allan

--
You received this message because you are subscribed to the Google Groups "vfx-platform-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-discuss+unsub...@googlegroups.com.
To post to this group, send email to vfx-platform-discuss@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/CAGq9Q7GaL-wEV%2BDfWRbYHgUP-MisY6VvD30nC%2BGbY3BhmpheAQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Nick Cannon]

On 21 February 2017 at 12:09, Chad Dombrova <cha...@gmail.com> wrote:

I suggest using rez as a starting point. We’ve created a custom build plugin for rez which adds functionality much like homebrew: it can retrieve source code from repos (git or hg) or archives (zip, tar, tar.gz, etc) living locally or remotely, and then run a series of build commands, before handing the result back to rez to finalize the release. It wouldn’t take much work to make it recursively build dependencies.

Rez is a good starting point for the following reasons:

Rez will certainly be considered, thank you for making the case for it.

We would want to make sure the build system is flexible enough to accommodate the diverse environment management schemes across studios and it should not impose any changes to existing methods. I'm sure rez is capable of that but I want to be clear that the built Platform should not require rez beyond the build process itself.

Nick

[Chad Dombrova]

We would want to make sure the build system is flexible enough to accommodate the diverse environment management schemes across studios and it should not impose any changes to existing methods. I'm sure rez is capable of that but I want to be clear that the built Platform should not require rez beyond the build process itself.

Makes sense.  By default rez installs into sub-directories by "variant", which is a very rez-specific scheme, but it should be fairly trivial to then flatten everything into a consolidated install prefix for those not using rez.  It would be an added benefit that those using rez could skip the last step and simply be ready to rock and roll.

-chad

[Allan Johns]

Furthermore, we could make sure that if every package build is cmake-based, those build scripts don't incorporate rez-specific features (or if they do, they are optional and will also work without). Rez's build tool (rez-build) just configures the build env, then runs the target build system within (cmake in this case) - the build scripts are free to use cmake-specific variables (such as CMAKE_INCLUDE_PATH) as they see fit.

A

--
You received this message because you are subscribed to the Google Groups "vfx-platform-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-discuss+unsub...@googlegroups.com.
To post to this group, send email to vfx-platform-discuss@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/117ae956-54bd-4169-92c2-6cb22270995d%40googlegroups.com.

[François Beaune]

The idea sounds fantastic, especially if Windows is a first class citizen.

With a bit of efforts, in addition to Linux and macOS, we manage to build the libraries we need (LLVM, ILMBase, OpenEXR, OIIO, OCIO, OSL...) on Windows with Visual Studio 2012/2013/2015.

Our main gripe right now is that we need to wrap all #include clauses of these libraries's headers with pragmas in order to silence the numerous warnings reported by Visual Studio:

https://github.com/appleseedhq/appleseed/blob/master/src/appleseed/foundation/platform/oiioheaderguards.h#L34-L46

Franz

--

You received this message because you are subscribed to the Google Groups "vfx-platform-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-discuss+unsub...@googlegroups.com.
To post to this group, send email to vfx-platform-discuss@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/CABiBYozkO2%2B%3DvkeAn_ZXJ%3DrpUbfqhypj%3DpvVxvXar2qMwPWG_A%40mail.gmail.com.

[Paul Miller]

On 2/23/17 3:18 AM, François Beaune wrote:

The idea sounds fantastic, especially if Windows is a first class citizen.

+1

[Larry Gritz]

Suggestion: send patches to the projects in question, in generally they would be happy to add these to their headers so that they don't make endless warnings on Windows.

Also, I'm no Windows or MSVC expert, but when using gcc or clang, there is a compiler flag -isystem that is similar to -I but instructs the compiler that the headers in that directory are "system libraries" that should not give warnings (since they are beyond your control to fix). So generally you'd want to "-isystem /path/to/OpenImageIO/include" rather than -I. I don't know if there's an equivalent with MSVC, but you might want to look into it.

On Feb 23, 2017, at 1:18 AM, François Beaune <dic...@gmail.com> wrote:

The idea sounds fantastic, especially if Windows is a first class citizen.

With a bit of efforts, in addition to Linux and macOS, we manage to build the libraries we need (LLVM, ILMBase, OpenEXR, OIIO, OCIO, OSL...) on Windows with Visual Studio 2012/2013/2015.

Our main gripe right now is that we need to wrap all #include clauses of these libraries's headers with pragmas in order to silence the numerous warnings reported by Visual Studio:

https://github.com/appleseedhq/appleseed/blob/master/src/appleseed/foundation/platform/oiioheaderguards.h#L34-L46

Franz

On Tue, Feb 21, 2017 at 6:52 AM, Nick Cannon <nick....@gmail.com> wrote:

There has been a steadily increasing demand for some form of automated build system for the VFX Reference Platform, for Windows and macOS in addition to Linux.

Such a system would provide an easier entry-point to building against the VFX Reference Platform as well as a more detailed specification for often requested information such as compiler flags and precise versions.

We are now starting work to coordinate a community effort to create such a system and have it validated by studios and vendors.

A handful of people across the industry have already offered to contribute to such an effort but we are looking for a few more. If you have relevant build engineering experience, particularly on macOS or Windows, and are willing to make a commitment to contributing then please email volu...@vfxplatform.com.

We are also seeking suggestions and opinions on what form such a system would take and what its scope should and should not include. Please share either by replying to this thread or privately to feed...@vfxplatform.com.

Thanks

Nick

--
Larry Gritz
l...@larrygritz.com

[Sam Richards]

I recently came across these "build clubs" for the recipes for creating certain apps on windows, OSX and Linux:

• https://github.com/vfxpro99/usd-build-club
  
• https://github.com/meshula/glew-build-club
  
• https://github.com/vfxpro99/boost-build-club

USD has a huge number of dependancies (OIIO, OpenSubdiv, Pyside, alembic, boost, glew, glext, glfw, hdf5, jpeg, openexr, png, ptex, pyside, python, qt, tiff, zlib), so its actually a pretty good basis for a multi-platform VFX-Platform.

What is interesting is the additional libraries USD-build-club refers to:

• https://github.com/vfxpro99/hdf5.git
  
• https://github.com/vadz/libtiff
  
• https://github.com/madler/zlib.git
  
• https://github.com/glennrp/libpng.git
  
• https://github.com/meshula/openexr.git
  

These are basically forks of the original code-base, where they have added in cmake support, and largely seem to keep up to date with updates.

I have not worked out who vfxpro99 is (Jeremy Cowles possibly), but meshula is  Nick Porcino. One of Nick's projects is https://github.com/meshula/mkvfx

which is a tool that builds open source libraries commonly used in games, film, and vfx, which clearly is an excellent starting point for a common build system.

However, I think the bigger point that Nick and vfxpro99 are building on is that we should be building on cmake where-ever possible, and that we should try to encourage the major VFX OSS projects that are not on cmake to adopt them. Additionally some of these forks that we might not be able to influence (e.g. libtiff or zlib) perhaps this is an area that either VES or the Academy can adopt, to make these github repos feel slightly more official, since I personally don't always like pulling a repo from a non-official site (not knowing what additional changes may have been made).

A sensible roadmap feels like:

1. Get the projects we have control of (e.g. openEXR) to add cmake support.
   
2. Figure out a framework for supporting the cmake forks.
   
3. Create a vfx-platform build-club which can procedurally build all of the packages, including gcc (where appropriate), using the usd-build-club and mkvfx as a starting point.
   
4. Provide a way to layer rez on top of this, for facilities that want versioned libraries.

Apologies if this is old news, I haven't really dug into the bad mad world of windows builds until this week.

Sam.

[Nick Cannon]

On 26 February 2017 at 09:15, Sam Richards <tau...@gmail.com> wrote:

A sensible roadmap feels like:

1. Get the projects we have control of (e.g. openEXR) to add cmake support.
   
2. Figure out a framework for supporting the cmake forks.
   
3. Create a vfx-platform build-club which can procedurally build all of the packages, including gcc (where appropriate), using the usd-build-club and mkvfx as a starting point.
   
4. Provide a way to layer rez on top of this, for facilities that want versioned libraries.

Thanks Sam. We already started the community effort I referenced at the start of this thread so I have added you and we should continue this roadmap discussion there.

Cheers,

Nick

[Allan Johns]

Encouraging standardized cmake build scripts is a really good way to go IMO. That includes the prerequisite that said scripts can be controlled via standard environment variables, such as {PKGNAME}_ROOT to direct any give install to a previously installed package.

I actually have a repo that's pretty old now, that was intended for this purpose:

https://github.com/nerdvegas/vfxcmake/tree/master/cmake

Thx

Allan

--
You received this message because you are subscribed to the Google Groups "vfx-platform-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-discuss+unsub...@googlegroups.com.
To post to this group, send email to vfx-platform-discuss@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/CABiBYowRNKxFNjNx%2BBQA%3Dw%2BWRi4snD5Kmh6HyRqUR5Y2Z4vvag%40mail.gmail.com.

[andersl...@gmail.com]

Has there been any more discussion on this off the list recently? I'm going through this again currently for 2018 on a development machine using Rez this time (which is great, thanks Allan!).

Most of the pain (on linux and macos at least, can't speak to windows) comes from the various different flavours of FindXXX.cmake that each package provides that all make some kind of broken assumptions about where your libraries are installed, what environment variables you might declare to try and aid that process, or in the case of Imath in particular, what the libraries are even called.

It would be nice if rather than each library trying to find its dependencies, each of those dependencies would instead provide a FindXXX.cmake for itself that explicitly creates imported targets to be used.

That way the dependent builds just need to make sure that FindXXX.cmake is in the CMAKE_MODULE_PATH somewhere, which is trivial either with a system install, Rez or some other build system.

[Allan Johns]

I'm a fan of this approach also.

In the past I've made package builds create and install their own FindXXX.cmake (typically in a cmake subdir in the installation) as part of the standard build.

In rez, said package has a commands() section that exposes its find module like so:

    def commands():

        if building:

            env.CMAKE_MODULE_PATH.append("{root}/cmake")

If you aren't using rez then you'd have to decide where the build should put these find modules so other builds can find them. There are some standard places that cmake looks (see: https://cmake.org/cmake/help/v3.6/command/find_package.html) but that often won't help because it's common to install to network shares. One idea might be to standardize on a particular cmake/environment variable that your build should respect, so that a given studio can control where all find modules get written to, and set their CMAKE_MODULE_PATH appropriately. To my knowledge cmake doesn't provide any guidance in this regard, but take that with a grain of salt as I haven't waded into the depths of cmake for a while.

Allan

--
You received this message because you are subscribed to the Google Groups "vfx-platform-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-discuss+unsub...@googlegroups.com.
To post to this group, send email to vfx-platform-discuss@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/291c0a1f-89b4-43e0-9ebb-4b9e174052aa%40googlegroups.com.

[Anders Langlands]

Yeah that's what I'm doing (manually) at the moment. I might try seeing if I can get ilmbase/openexr to generate them automatically as a starting point, but right now my commands() is filled with various permutations env.OPENEXR_HOME, env.OPENEXR_ROOT, env.OPENEXR_LOCATION etc...

By the environment variable that cmake should respect, do you mean where it should install it to? As in something like CMAKE_INSTALL_MODULE_PATH or something? I don't know of anything like that currently - doesn't mean it doesn't exist but cmake "standards" seem to be a nebulous thing spread across dozens of stackoverflow answers...

On Thu, 7 Dec 2017 at 17:32 Allan Johns <nerd...@gmail.com> wrote:

I'm a fan of this approach also.

In the past I've made package builds create and install their own FindXXX.cmake (typically in a cmake subdir in the installation) as part of the standard build.

In rez, said package has a commands() section that exposes its find module like so:

    def commands():

        if building:

            env.CMAKE_MODULE_PATH.append("{root}/cmake")

If you aren't using rez then you'd have to decide where the build should put these find modules so other builds can find them. There are some standard places that cmake looks (see: https://cmake.org/cmake/help/v3.6/command/find_package.html) but that often won't help because it's common to install to network shares. One idea might be to standardize on a particular cmake/environment variable that your build should respect, so that a given studio can control where all find modules get written to, and set their CMAKE_MODULE_PATH appropriately. To my knowledge cmake doesn't provide any guidance in this regard, but take that with a grain of salt as I haven't waded into the depths of cmake for a while.

Allan

On Thu, Dec 7, 2017 at 5:47 AM, <andersl...@gmail.com> wrote:

Has there been any more discussion on this off the list recently? I'm going through this again currently for 2018 on a development machine using Rez this time (which is great, thanks Allan!).

Most of the pain (on linux and macos at least, can't speak to windows) comes from the various different flavours of FindXXX.cmake that each package provides that all make some kind of broken assumptions about where your libraries are installed, what environment variables you might declare to try and aid that process, or in the case of Imath in particular, what the libraries are even called.

It would be nice if rather than each library trying to find its dependencies, each of those dependencies would instead provide a FindXXX.cmake for itself that explicitly creates imported targets to be used.

That way the dependent builds just need to make sure that FindXXX.cmake is in the CMAKE_MODULE_PATH somewhere, which is trivial either with a system install, Rez or some other build system.

--
You received this message because you are subscribed to the Google Groups "vfx-platform-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-dis...@googlegroups.com.

To post to this group, send email to vfx-platfo...@googlegroups.com.

[guillaume papin]

IMHO, if you have the opportunity to add some informations to the package installation, you should not modify FindXxx.cmake and CMAKE_MODULE_PATH and <PROJECT>_ROOT kind of things.

Instead you should install a xxx-config.cmake, and just use CMAKE_PREFIX_PATH.

When installing a package, you can patch it to install a file named xxx-config.cmake to <prefix>/lib/cmake/<project> (should work on Linux/macOS/Windows):

    include(GNUInstallDirs)

    set(CMAKE_CONFIG_INSTALL_DIR ${CMAKE_INSTALL_LIBDIR}/cmake/${PROJECT_NAME})

    install(TARGETS ${PROJECT_NAME}

            EXPORT ${PROJECT_NAME}-targets

            LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}

            ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}

            RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR})

    install(EXPORT ${PROJECT_NAME}-targets

            NAMESPACE ${PROJECT_NAME}::

            DESTINATION ${CMAKE_CONFIG_INSTALL_DIR})

    install(FILES cmake/${PROJECT_NAME}-config.cmake

            DESTINATION ${CMAKE_CONFIG_INSTALL_DIR})

Using rez, then the package can declare its prefix path like this (I don't use it but that's what I did when I experimented with it):

    def commands():

        if building:

            env.CMAKE_PREFIX_PATH.append("{root}")

A good resource on CMake packages is the CMake documentation itself, the whole page is worse reading, it's longer more complicated than one should hope for, but it works:

- https://cmake.org/cmake/help/v3.9/manual/cmake-packages.7.html#package-layout

---

From: vfx-platfo...@googlegroups.com <vfx-platfo...@googlegroups.com> on behalf of Anders Langlands <andersl...@gmail.com>
Sent: Thursday, December 7, 2017 9:21:08 AM
To: Allan Johns
Cc: vfx-platform-discuss
Subject: Re: [vfx-platform-discuss] Creating an automated build system

 

To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/CAFAj8BFecf-OHha6RyQocuGYQRqsvZL-hiQskKR4zgUDbDGHgA%40mail.gmail.com.

[Allan Johns]

I did read a little about the xxx-config.cmake approach but I don't know much about it, is it relatively new?

@Anders: I meant that in order to have a known location to find cmake find modules, and assuming that software is often installed onto shares, we'd have to settle on some standard env-var that vfx cmake builds would adhere to. Kinda like Guillaume's CMAKE_CONFIG_INSTALL_DIR, but not assuming that it'd be somewhere within the cmake installation (which I've read is not recommended anyway and I tend to agree).

So for example, if CMAKE_CONFIG_INSTALL_DIR was the agreed var, then rez builds would just set this to "{root}/cmake", and non-rez builds might set it to some share location such as "/software/cmake".

A

On Thu, Dec 7, 2017 at 7:52 PM, guillaume papin <guillau...@epitech.eu> wrote:

IMHO, if you have the opportunity to add some informations to the package installation, you should not modify FindXxx.cmake and CMAKE_MODULE_PATH and <PROJECT>_ROOT kind of things.

Instead you should install a xxx-config.cmake, and just use CMAKE_PREFIX_PATH.

When installing a package, you can patch it to install a file named xxx-config.cmake to <prefix>/lib/cmake/<project> (should work on Linux/macOS/Windows):

    include(GNUInstallDirs)

    set(CMAKE_CONFIG_INSTALL_DIR ${CMAKE_INSTALL_LIBDIR}/cmake/${PROJECT_NAME})

    install(TARGETS ${PROJECT_NAME}

            EXPORT ${PROJECT_NAME}-targets

            LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}

            ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}

            RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR})

    install(EXPORT ${PROJECT_NAME}-targets

            NAMESPACE ${PROJECT_NAME}::

            DESTINATION ${CMAKE_CONFIG_INSTALL_DIR})

    install(FILES cmake/${PROJECT_NAME}-config.cmake

            DESTINATION ${CMAKE_CONFIG_INSTALL_DIR})

Using rez, then the package can declare its prefix path like this (I don't use it but that's what I did when I experimented with it):

    def commands():

        if building:

            env.CMAKE_PREFIX_PATH.append("{root}")

A good resource on CMake packages is the CMake documentation itself, the whole page is worse reading, it's longer more complicated than one should hope for, but it works:

- https://cmake.org/cmake/help/v3.9/manual/cmake-packages.7.html#package-layout

---

From: vfx-platform-discuss@googlegroups.com <vfx-platform-discuss@googlegroups.com> on behalf of Anders Langlands <andersl...@gmail.com>

Sent: Thursday, December 7, 2017 9:21:08 AM
To: Allan Johns
Cc: vfx-platform-discuss
Subject: Re: [vfx-platform-discuss] Creating an automated build system

Yeah that's what I'm doing (manually) at the moment. I might try seeing if I can get ilmbase/openexr to generate them automatically as a starting point, but right now my commands() is filled with various permutations env.OPENEXR_HOME, env.OPENEXR_ROOT, env.OPENEXR_LOCATION etc...

By the environment variable that cmake should respect, do you mean where it should install it to? As in something like CMAKE_INSTALL_MODULE_PATH or something? I don't know of anything like that currently - doesn't mean it doesn't exist but cmake "standards" seem to be a nebulous thing spread across dozens of stackoverflow answers...

On Thu, 7 Dec 2017 at 17:32 Allan Johns <nerd...@gmail.com> wrote:

I'm a fan of this approach also.

In the past I've made package builds create and install their own FindXXX.cmake (typically in a cmake subdir in the installation) as part of the standard build.

In rez, said package has a commands() section that exposes its find module like so:

    def commands():

        if building:

            env.CMAKE_MODULE_PATH.append("{root}/cmake")

If you aren't using rez then you'd have to decide where the build should put these find modules so other builds can find them. There are some standard places that cmake looks (see: https://cmake.org/cmake/help/v3.6/command/find_package.html) but that often won't help because it's common to install to network shares. One idea might be to standardize on a particular cmake/environment variable that your build should respect, so that a given studio can control where all find modules get written to, and set their CMAKE_MODULE_PATH appropriately. To my knowledge cmake doesn't provide any guidance in this regard, but take that with a grain of salt as I haven't waded into the depths of cmake for a while.

Allan

On Thu, Dec 7, 2017 at 5:47 AM, <andersl...@gmail.com> wrote:

Has there been any more discussion on this off the list recently? I'm going through this again currently for 2018 on a development machine using Rez this time (which is great, thanks Allan!).

Most of the pain (on linux and macos at least, can't speak to windows) comes from the various different flavours of FindXXX.cmake that each package provides that all make some kind of broken assumptions about where your libraries are installed, what environment variables you might declare to try and aid that process, or in the case of Imath in particular, what the libraries are even called.

It would be nice if rather than each library trying to find its dependencies, each of those dependencies would instead provide a FindXXX.cmake for itself that explicitly creates imported targets to be used.

That way the dependent builds just need to make sure that FindXXX.cmake is in the CMAKE_MODULE_PATH somewhere, which is trivial either with a system install, Rez or some other build system.

--
You received this message because you are subscribed to the Google Groups "vfx-platform-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-discuss+unsub...@googlegroups.com.

To post to this group, send email to vfx-platform-discuss@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/291c0a1f-89b4-43e0-9ebb-4b9e174052aa%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "vfx-platform-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-discuss+unsub...@googlegroups.com.
To post to this group, send email to vfx-platform-discuss@googlegroups.com.

[guillaume papin]

> I did read a little about the xxx-config.cmake approach but I don't know much about it, is it relatively new?

Not really, it seems to be present at least since CMake 2.8.6 (October 2011).

Really, if you have a package manager where you can tweak the build, xxx-config.cmake + CMAKE_PREFIX_PATH is the 2nd best method.

The best method being that the upstream package install the xxx-config.cmake itself.

> Kinda like Guillaume's CMAKE_CONFIG_INSTALL_DIR, but not assuming that it'd be somewhere within the cmake installation (which I've read is not recommended anyway and I tend to agree).

CMAKE_CONFIG_INSTALL_DIR is not a path withing the CMake installation.

It is a relative path to the package install prefix.

So for a package foo, installed in the directory /my-share/package/foo, you would have:

/my-share/package/foo/

- bin/foo

- include/foo.h

- lib/libfoo.so

- lib/cmake/foo/foo-config.cmake

- lib/cmake/foo/foo-targets.cmake

I believe pkg-config works the same, you could have:

- lib/pkgconfig/foo.pc

Then you get a nice symmetry.

To install a package you do: cmake -DCMAKE_INSTALL_PREFIX=/my-share/package/foo/

To consume a package, you do: cmake -DCMAKE_PREFIX_PATH=/my-share/package/foo/

---

From: Allan Johns <nerd...@gmail.com>
Sent: Thursday, December 7, 2017 10:06:28 PM
To: guillaume papin
Cc: Anders Langlands; vfx-platform-discuss

[Allan Johns]

Ah, thanks for the clarification RE CMAKE_CONFIG_INSTALL_DIR. Seems like using INSTALL_PREFIX/PREFIX_PATH with rez could be a nice way to go - downstream builds would then be able to use the FIND_XXX native macros without needing to INCLUDE anything.

Cheers

A

To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-discuss+unsubscrib...@googlegroups.com.

To post to this group, send email to vfx-platform-discuss@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/291c0a1f-89b4-43e0-9ebb-4b9e174052aa%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "vfx-platform-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-discuss+unsubscrib...@googlegroups.com.

To post to this group, send email to vfx-platform-discuss@googlegroups.com.

[Patrick Hodoul]

Another completely different approach could be to create a github project with a python script to grab & compile various libraries (as listed by VES) along with a bunch of configuration files (e.g. one per year, listing version of libraries) ). The usage could be something like  "python compile.py ocio ves2017" By having a github project the VES committee could update the files when a new library version must be used or create a new configuration file.

Currently writing a dockerfile (for ubuntu 16.04) to compile OCIO (lot of installed libraries plus few library compilations), the conversion to a script should not be too complex. Sean Copper already put in review a centOS dockerfile for OCIO if you would like to see an example. Our goal is to provide an easy way to compile OCIO on different *nix platforms. But an interesting side-effect is to document needs to compile OCIO. As you could see, the conversion of this file to a bash script or python file could be straight forward.

As usual Windows is problematic, a tool like vcpkg could certainly help to have the same kind of commands (compare to apt-get or yum) and so having a uniform python script with *nix platforms.

Patrick.

On Thursday, February 23, 2017 at 4:18:18 AM UTC-5, François Beaune wrote:

The idea sounds fantastic, especially if Windows is a first class citizen.

With a bit of efforts, in addition to Linux and macOS, we manage to build the libraries we need (LLVM, ILMBase, OpenEXR, OIIO, OCIO, OSL...) on Windows with Visual Studio 2012/2013/2015.

Our main gripe right now is that we need to wrap all #include clauses of these libraries's headers with pragmas in order to silence the numerous warnings reported by Visual Studio:

https://github.com/appleseedhq/appleseed/blob/master/src/appleseed/foundation/platform/oiioheaderguards.h#L34-L46

Franz

On Tue, Feb 21, 2017 at 6:52 AM, Nick Cannon <nick....@gmail.com> wrote:

There has been a steadily increasing demand for some form of automated build system for the VFX Reference Platform, for Windows and macOS in addition to Linux.

Such a system would provide an easier entry-point to building against the VFX Reference Platform as well as a more detailed specification for often requested information such as compiler flags and precise versions.

We are now starting work to coordinate a community effort to create such a system and have it validated by studios and vendors.

A handful of people across the industry have already offered to contribute to such an effort but we are looking for a few more. If you have relevant build engineering experience, particularly on macOS or Windows, and are willing to make a commitment to contributing then please email volu...@vfxplatform.com.

We are also seeking suggestions and opinions on what form such a system would take and what its scope should and should not include. Please share either by replying to this thread or privately to feed...@vfxplatform.com.

Thanks

Nick

--
You received this message because you are subscribed to the Google Groups "vfx-platform-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-discuss+unsub...@googlegroups.com.

To post to this group, send email to vfx-platfo...@googlegroups.com.

[Anders Langlands]

The trouble with that is it will almost certainly install things somewhere other than where I want them and now I have to debug yet another script to figure out why the build is breaking on my system...

To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-dis...@googlegroups.com.

To post to this group, send email to vfx-platfo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/CABiBYozkO2%2B%3DvkeAn_ZXJ%3DrpUbfqhypj%3DpvVxvXar2qMwPWG_A%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "vfx-platform-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vfx-platform-discuss/1g0pt4hhjqg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vfx-platform-dis...@googlegroups.com.

To post to this group, send email to vfx-platfo...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/8039432c-e75a-4c32-bcee-543e2834ca17%40googlegroups.com.

[Patrick Hodoul]

Nothing is perfect I agree.

On the other hand, some open source projects have a way to specify an install path (and others could be changed to have one) and finally, everyone will benefit from any improvements needed by one.

Most of the applications at Autodesk at least need ilmbase, openEXR, oiio, ocio, boost ... It seems that there is a set of core libraries which could benefit from being bundled.

And that 'bundle' could be maintained & validated by the VES committee using the VES machines and/or using Travis and appVeyor with the predefined configurations...

On Thursday, December 7, 2017 at 10:07:22 PM UTC-5, Anders Langlands wrote:

The trouble with that is it will almost certainly install things somewhere other than where I want them and now I have to debug yet another script to figure out why the build is breaking on my system...

On Fri, 8 Dec 2017 at 15:33 Patrick Hodoul <patric...@gmail.com> wrote:

Another completely different approach could be to create a github project with a python script to grab & compile various libraries (as listed by VES) along with a bunch of configuration files (e.g. one per year, listing version of libraries) ). The usage could be something like  "python compile.py ocio ves2017" By having a github project the VES committee could update the files when a new library version must be used or create a new configuration file.

Currently writing a dockerfile (for ubuntu 16.04) to compile OCIO (lot of installed libraries plus few library compilations), the conversion to a script should not be too complex. Sean Copper already put in review a centOS dockerfile for OCIO if you would like to see an example. Our goal is to provide an easy way to compile OCIO on different *nix platforms. But an interesting side-effect is to document needs to compile OCIO. As you could see, the conversion of this file to a bash script or python file could be straight forward.

As usual Windows is problematic, a tool like vcpkg could certainly help to have the same kind of commands (compare to apt-get or yum) and so having a uniform python script with *nix platforms.

Patrick.

On Thursday, February 23, 2017 at 4:18:18 AM UTC-5, François Beaune wrote:

The idea sounds fantastic, especially if Windows is a first class citizen.

With a bit of efforts, in addition to Linux and macOS, we manage to build the libraries we need (LLVM, ILMBase, OpenEXR, OIIO, OCIO, OSL...) on Windows with Visual Studio 2012/2013/2015.

Our main gripe right now is that we need to wrap all #include clauses of these libraries's headers with pragmas in order to silence the numerous warnings reported by Visual Studio:

https://github.com/appleseedhq/appleseed/blob/master/src/appleseed/foundation/platform/oiioheaderguards.h#L34-L46

Franz

On Tue, Feb 21, 2017 at 6:52 AM, Nick Cannon <nick....@gmail.com> wrote:

There has been a steadily increasing demand for some form of automated build system for the VFX Reference Platform, for Windows and macOS in addition to Linux.

Such a system would provide an easier entry-point to building against the VFX Reference Platform as well as a more detailed specification for often requested information such as compiler flags and precise versions.

We are now starting work to coordinate a community effort to create such a system and have it validated by studios and vendors.

A handful of people across the industry have already offered to contribute to such an effort but we are looking for a few more. If you have relevant build engineering experience, particularly on macOS or Windows, and are willing to make a commitment to contributing then please email volu...@vfxplatform.com.

We are also seeking suggestions and opinions on what form such a system would take and what its scope should and should not include. Please share either by replying to this thread or privately to feed...@vfxplatform.com.

Thanks

Nick

--
You received this message because you are subscribed to the Google Groups "vfx-platform-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-discuss+unsub...@googlegroups.com.

To post to this group, send email to vfx-platfo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/CABiBYozkO2%2B%3DvkeAn_ZXJ%3DrpUbfqhypj%3DpvVxvXar2qMwPWG_A%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "vfx-platform-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vfx-platform-discuss/1g0pt4hhjqg/unsubscribe.

To unsubscribe from this group and all its topics, send an email to vfx-platform-discuss+unsub...@googlegroups.com.

[bobe...@gmail.com]

This would be great! I'm currently maintaining where possible a Windows build of Gaffer's dependencies (which align with the VFX reference platform) and often I've been needing to find an alternative CMake build system for its dependencies on Windows (eg. Python2.7 plus patches to fix compilation on MSVC2015/2017). If anyone is interested here it is, it might help here:
https://github.com/boberfly/gafferdependencies/tree/windows2

Currently build/ contains the macOS/Linux build scripts that John & contributors maintain, and winbuild/ are the ones I've written as Windows batch files, but most likely a python script which can do all OSes would be ideal. I was thinking of using something like fips here which is designed around configuring CMake from python, but rez could make more sense.

[Edward Lam]

I second sending patches upstream although it doesn't help with the immediate problem because they don't go away until the VFX platform updates to the version with the fix.

On MSVC, there's no equivalent to -isystem so I've taken to just patching the headers directly to fix warnings that show up when using them.

-Edward

--
You received this message because you are subscribed to the Google Groups "vfx-platform-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-dis...@googlegroups.com.
To post to this group, send email to vfx-platfo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/DEFAF205-0B30-464F-944B-B2644583818F%40larrygritz.com.

For more options, visit https://groups.google.com/d/optout.

--

Support us by rating GOToronto in the App Store!

[Larry Gritz]

I'd like to see the list be understood to mean "this version, or any subsequent update that is fully API/ABI compatible," with a more dynamic way to update the list with those additional versions, as communicated by the software maintainers. I don't think it's helpful (and probably not intended) to ossify around a known broken version when compatible fixes exist.

Maybe that's already the interpretation of the VFXPlatform leadership, but perhaps nobody knows it so they don't send updates.

-- lg

To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/CAJZe6MC7JOkEri7OgkHFgUa9VwEpA4SMRzezzWDPvWEkTE%3DN%3DA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Larry Gritz

l...@larrygritz.com

[Nick Cannon]

On 19 February 2018 at 08:42, Larry Gritz <l...@larrygritz.com> wrote:

I'd like to see the list be understood to mean "this version, or any subsequent update that is fully API/ABI compatible," with a more dynamic way to update the list with those additional versions, as communicated by the software maintainers. I don't think it's helpful (and probably not intended) to ossify around a known broken version when compatible fixes exist.

Maybe that's already the interpretation of the VFXPlatform leadership, but perhaps nobody knows it so they don't send updates.

That is indeed the intent although we don't explicitly call that out on the web site. If there are API/ABI compatible changes we can make to the Platform to resolve issues then please send to feed...@vfxplatform.com and we will do our best to validate with software vendors and update the site promptly.

Thanks,

Nick

[bye...@gmail.com]

I'd be very interested in using a set of common prebuilt binaries, at the moment I am building and using the usual suspects on all platforms (win/mac/linux/iOS) and it's a bit of a pain to have to rebuild & test things all the time, as a result I end up not updating libraries as often, which I'm sure it's happening to more people.

Did this ever get anywhere?

[Nick Cannon]

On Thursday, February 22, 2018 at 10:21:54 PM UTC-8, Javier Edo wrote:

I'd be very interested in using a set of common prebuilt binaries, at the moment I am building and using the usual suspects on all platforms (win/mac/linux/iOS) and it's a bit of a pain to have to rebuild & test things all the time, as a result I end up not updating libraries as often, which I'm sure it's happening to more people.

Did this ever get anywhere?

Yes, there is activity happening around an automated build system which seems promising. Hopefully there will be more information able to be shared about this in the coming months, by SIGGRAPH if not before.

Nick 

[bye...@gmail.com]

Thanks! I'm hoping it gains some momentum as I think that the fact that this isn't set up (yet) forces a lot of people find their own ways and thus end up patching libraries everyone in their own way.

As an example, I started to test Autodesk's public branch of Qt 5.6.x only to realize that QGLWidget(s) are barely usable under MacOS (unless you don't mind a billion runtime warnings in 2 monitor setups, which is the norm in vfx) and QOpenGLWidget(s) don't support Remote Desktop under Windows (black screen) and don't play well with non-Qt-created Framebuffers and don't support sRGB framebuffers (although this has been added to mainline Qt 5.10, so it can be cherry picked and merged there although I don't know if Autodesk would accept it. (although I get that people might be avoiding this last one by using a 3d lut from OCIO...)

I'm curious about how people get around these, whilst staying on "vfxplatform-approved" libraries. I guess they just patch them and get on with other stuff.

GL under Qt5+ seems worse than it was under Qt4, or I may have hit each and every "weak point" it has.

[Michael Rochefort]

How far would this system go? Are we talking about just building the core libraries and maybe Python bindings? Or would these include toolkit’s like those from OpenVDB? The latter would be a nice touch (as getting things working on Windows is a pain) but probably not the priority considering the other bundles of libraries they need. 

Cheers,

Mike

---- On Fri, 23 Feb 2018 04:59:51 -0500 bye...@gmail.com<bye...@gmail.com> wrote ----

--
You received this message because you are subscribed to the Google Groups "vfx-platform-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-disc...@googlegroups.com.

To post to this group, send email to vfx-platfo...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/4befeab0-435d-4e93-bc1c-12daf78fadd2%40googlegroups.com.

[Ryan Bottriell]

My team has had a lot of success lately using googles Bazel build system (https://bazel.build/). Honestly just an idea to throw in the mix. I can't say that I have thought through the full scope of the requirements here, but it has an excellent community and great support for handling different languages and large sets of dependencies.

Cheers,

Ryan Bottriell

[Edward Lam]

I think that what's important for these packages is a large ecosystem of packages and maintainers. Debian had this right but it's not very cross platform if people care about this aspect. Of lately, I noticed that vcpkg has OpenVDB and all of its dependencies, and it even officially supports all 3 platforms by standardizing on CMake. So that sounds like a step in the right direction to me rather than create new build systems for all these packages without steady support from upstream.

-Edward

--

You received this message because you are subscribed to the Google Groups "vfx-platform-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-dis...@googlegroups.com.

To post to this group, send email to vfx-platfo...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/68192771-3de2-4b4b-8a16-a2103918c047%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Larry Gritz]

I'm sure that the merits of Bazel are good, but it seems like CMake is starting to dominate both open source generally and also studio proprietary builds (in many places). Even if not universal, it's widespread enough that we get a nice network effect from so many packages using it and so many people understanding it. I would be very surprised if anybody was inclined to want to rewrite build systems yet again, and I would expect that open source projects using anything other than cmake would have to work a lot harder to get any traction (at this point, we'll see where we are in a few years -- it's just like how a C++ project is going to get more traction than a Rust project, say, regardless of its theoretical merit).

To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/CAJZe6MDD7LNvA-j3%3D1YeoTFXMW4dfE%2Bq5kdTHBdoJOXOuNj7wA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Larry Gritz

l...@larrygritz.com

[Nick Porcino]

Microsoft's vcpkg is an interesting case in point. For the most part, it's a somewhat opinionated cmake based build of a huge swath of open source, but to pull it off, a percentage of projects are not vanilla cmake builds, but require patches to work around various issues. Poke randomly in this directory to see -

https://github.com/Microsoft/vcpkg/tree/master/ports

In order to make this work, they kind of need you to use their toolchain file which has further patches for all the bugs in problematic Find algorithms.

https://github.com/Microsoft/vcpkg/tree/master/scripts

This is a bit different than the approach I took in mkvfx ( https://github.com/vfxpro99/mkvfx ), which takes the approach of never patching except in the most egregious of cases, rather, it issues super explicit cmake command lines to coerce reasonable behavior.

Neither approach is exactly pleasant.

It would be nice for upstream projects' cmake scripts to be less horrific to minimize the need for these shenanigans.

We've been stabbing at the OpenEXR cmakes recently, so soon it'll be one down, a zillion to go ;)

Cmake still feels like a best hope for the reasons Larry mentions.

On Tuesday, June 12, 2018 at 11:30:45 AM UTC-7, Larry Gritz wrote:

I'm sure that the merits of Bazel are good, but it seems like CMake is starting to dominate both open source generally and also studio proprietary builds (in many places). Even if not universal, it's widespread enough that we get a nice network effect from so many packages using it and so many people understanding it. I would be very surprised if anybody was inclined to want to rewrite build systems yet again, and I would expect that open source projects using anything other than cmake would have to work a lot harder to get any traction (at this point, we'll see where we are in a few years -- it's just like how a C++ project is going to get more traction than a Rust project, say, regardless of its theoretical merit).

On Jun 11, 2018, at 6:28 PM, Edward Lam <triplequ...@gmail.com> wrote:

I think that what's important for these packages is a large ecosystem of packages and maintainers. Debian had this right but it's not very cross platform if people care about this aspect. Of lately, I noticed that vcpkg has OpenVDB and all of its dependencies, and it even officially supports all 3 platforms by standardizing on CMake. So that sounds like a step in the right direction to me rather than create new build systems for all these packages without steady support from upstream.

-Edward

On Sun, Jun 10, 2018, 8:52 PM Ryan Bottriell, <ryanbo...@gmail.com> wrote:

My team has had a lot of success lately using googles Bazel build system (https://bazel.build/). Honestly just an idea to throw in the mix. I can't say that I have thought through the full scope of the requirements here, but it has an excellent community and great support for handling different languages and large sets of dependencies.

Cheers,

Ryan Bottriell

--

Larry Gritz

l...@larrygritz.com

[David Aguilar]

Hello, I just wanted to agree that "modern" cmake[1] seems like the
best hope for us as well.

I recently took a stab at slightly modernizing Ptex's cmake setup[2]
in case anyone wants to see some concrete examples. We now export our
targets so that downstream products need only find_package(Ptex) to
make our exported targets available. I agree that if we could get
everyone using modern cmake semantics then it would help minimize the
tweaks needed to get things building for everyone. We also tend to
take a similar approach of, "don't patch unless we absolutely need
to", so getting these improvements pushed upstream would be a benefit
to everyone.

This does bring up the point that a lot of nice cmake features related
to packaging and exporting targets landed in cmake 3.0. If the VFX
Reference Platform specified that projects can expect a minimum of
cmake 3.0 then that would give us a good baseline when updating
existing projects. For reference, cmake 3.0 was released 4 years ago.

[1] https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/

[2] https://github.com/wdas/ptex/pull/35

cheers,
David

[Larry Gritz]

I would love to see a minimum cmake version specified in VFXPlatform. It would really help the maintainers of all these packages to have a solid idea of which cmake features we could target.

-- lg

--
You received this message because you are subscribed to the Google Groups "vfx-platform-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-dis...@googlegroups.com.
To post to this group, send email to vfx-platfo...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/CAGd_kMDk0-MT2Y%2B6UGcvdNamrWw1oGohsrbHQE3DoL777JZ_sA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Larry Gritz

l...@larrygritz.com

[Nick Cannon]

On Fri, 29 Jun 2018 at 16:43, Larry Gritz <l...@larrygritz.com> wrote:

I would love to see a minimum cmake version specified in VFXPlatform. It would really help the maintainers of all these packages to have a solid idea of which cmake features we could target.

Would anyone object to, or see any issues with, specifying cmake 3.0 or later for CY2019? Does anyone think it is unnecessary or undesirable? Please reply here or privately to feed...@vfxplatform.com.

Can certainly add it into the mix for consideration for the Final version.

Nick

[Larry Gritz]

On Jun 29, 2018, at 9:55 PM, Nick Cannon <nick....@gmail.com> wrote:

Would anyone object to, or see any issues with, specifying cmake 3.0 or later for CY2019? Does anyone think it is unnecessary or undesirable? Please reply here or privately to feed...@vfxplatform.com.

Can certainly add it into the mix for consideration for the Final version.

Nick

I have no specific objections to 3.0 -- that's the minimum I currently write for, and much better than no guidance at all.

But please note that as a 2014 release, it would be one of the most outdated packages in the VFX Platform 2019 recommendations.

--

Larry Gritz

l...@larrygritz.com

[Anders Langlands]

Why not just go straight for 3.11?

--
You received this message because you are subscribed to a topic in the Google Groups "vfx-platform-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vfx-platform-discuss/1g0pt4hhjqg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vfx-platform-dis...@googlegroups.com.

To post to this group, send email to vfx-platfo...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/8AD7F89D-A38B-4127-8131-B251F928628B%40larrygritz.com.

[Nick Porcino]

Due to the way cmake handles boost/Visual Studio combinations, cmake < 3.9 is effectively unusable on vs2017. 3.10 sorta kinda works, and 3.11 is fine. Due to the way microsoft is treating compiler deployment (more Apple-ish "update or become obsolete", less "pick your poison"), adoption of vs2017 is much more rapid than previous compiler iterations. So this is me wishing for 3.11. Also, this is me wishing that the cmake official FindBoost script was not so break-prone.

[Nick Porcino]

Thanks for those links. I see a bunch of things I can use immediately, and it's great to have a concise reference to idiomatic modern cmake usage :)

[Larry Gritz]

I take that back, I was incorrect. Both of the widely-used open source projects I maintain require a minimum of cmake 3.2.2.

[Larry Gritz]

+1, thanks David. My cmake idioms are out of date (so's my cmake -- I'm still using 3.2), and I have a lot to learn from those links.

--
You received this message because you are subscribed to the Google Groups "vfx-platform-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-dis...@googlegroups.com.
To post to this group, send email to vfx-platfo...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/f27afc20-103d-4aa4-9457-7e87eda860ea%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Larry Gritz

l...@larrygritz.com

[Nick Cannon]

On Friday, June 29, 2018 at 4:43:41 PM UTC-7, Larry Gritz wrote:

I would love to see a minimum cmake version specified in VFXPlatform. It would really help the maintainers of all these packages to have a solid idea of which cmake features we could target.

The stated aim of the Platform is to address versionitis and the addition of cmake would not help with that.

Versionitis aside, encouraging use of a minimum cmake would be helpful but I suggest the industry finds other means to do that rather than using the VFX Reference Platform.

Nick