charlesangus / DeepC

Suite of Deep compositing tools for Foundry's Nuke.
GNU General Public License v3.0
103 stars 13 forks source link

CMake: loop through appropriate Nuke versions available/found #55

Closed charlesangus closed 2 years ago

charlesangus commented 2 years ago

Ideally one run of the CMake build routine would build for all installed Nuke versions >=11.2

jonassorgenfrei commented 2 years ago

I would suggest to create a batch/shell file to loop over all (installed) Nuke versions and alter the cmake build.

cmake -DCMAKE_INSTALL_PREFIX=install<version> -DNuke_ROOT="C:/Program Files/Nuke<version>" -B build<version>
make install

To overwrite the Nuke_ROOT-directory we need to set the CMP0074 policy to new:

cmake_policy(SET CMP0074 NEW)

I haven't seen a lot of CMake-Files having the behaviour itself to build for multiple versions of an application. Plus this probably make the CMake file very complicated too tho since it needs default build direcotries for each versoin and the linking itself gets very complicated too.

If you like i can provide these suggested scripts. And we could include them aswell as an example which should be easily be adjustable for non default install directories.

charlesangus commented 2 years ago

So the idea is instead of invoking CMake directly, you run e.g. buildall.sh in the root of the repo? Doesn't that defeat the purpose of cmake a little, e.g. by bypassing it finding nuke automatically and introducing a platform-specific dependency?

Also would need a .bat file or whatever for Windows I guess if we go that route.

Maybe I'm not understanding exactly.

jonassorgenfrei commented 2 years ago

Yeah so the Idea of CMake is finding any matching library. As far as i know cmake is not really working with finding multiple versions of a library or espacially using them. But be I'm wrong?? Currently finding the cmake library is creating a lot of possible directories given by different: _nuke_KNOWN_VERSIONS with the patches altering from 1 to 13 at their common directories. And Searching Top->Bottom for any matching library, taking the first match. To implement your behvaiour it would make the Cmake file very complicated to understand/read, since for every version you would have to iterate over the whole building/linking process in Cmake and probably having differnt output variables like: NUKE_FOUND_13_1_1 or so. As well as the find_library just returns the first match and not mutliple libraries. And it's for example not possible to instead of building all or one jsut build version-x + version-y.

Aswell if you for example have nuke installed somewhere else for example D:/programms/nuke.. or /opt/nuke.. the auto find nuke cmake will fail too.

I guess most people are fine with having just the plugin for the last installed version. To handle the occurence of multiple libraries you can overwrite the Nuke_ROOT as it is implemented in: FindNuke.cmake (Alternatively Nuke_FINDVERSION* variables) An example where this is used very often is for binding the right boost verison in CPP applications. Since most of the find_XYZ cmake config files are just finding one version.

So my suggestion would be to have a sh/bat file or may be even better a python command-line which will (yeah i admit) search aswell for the nuke libraries in the os. But there we can add the behaviour of for example showing versions find. Like builder.py -show-versions

So yeah in short the idea is to just have a wrapper for batching the build process for multiple nuke versions to keep the cmake file clean for editing when adding nodes/libraries.

charlesangus commented 2 years ago

Gotcha, yeah. Python wrapper is probably best, so it's cross-platform (now that you have windows working, that actually matters heh).

Could also start building in some simple testing, too, possibly.

jonassorgenfrei commented 2 years ago

grafik Got a first test running nicely on Windows.

Went to a shell script instead of a python script for now. But couldnt get a zip-compress post running for releases, so may be i have to go back to a python script for it, but not pretty sure about the subprocess to compile everything. Actually i would prefer the Shell Script. Tho.

You can have a look in my fork repo (https://github.com/jonassorgenfrei/DeepC) @falkhofmann could you give it a try on linux the next days?

jonassorgenfrei commented 2 years ago

DONE :) It's the batchInstall.sh file. Will add a description to the readme in the next days.