(Bez) Build System Global Override?

[Benjamin Rhoades]

Hey all,

I'm curious if anyone has any suggestions on the best way to have a "global" override for the Bez build system.

I'm still setting up Rez for my studio, and I'm trying to streamline the process for our TDs as much as possible. Most of our projects are pure python, and are built using the same general template. This means that our rezbuild.py for each of these packages look nearly identical. It'd be great to have a way to set up a "global" rezbuild.py that can be overridden locally if needed. Sort of like the way Rez has the preprocess_package functionality that can be specified in the rezconfig to modify the package definition from a central location. 

As a practical example, we have a lot of projects that contain configuration yaml files that, under our previous deployment system, have several values toggled when they are released to the production environment.

I've already found the "REZ_BUILD_TYPE" environment variable, which can inform the install that the package is being deployed to the central repository. What I'd love though, to keep the rezbuild.py files for each package simple and manageable, is to be able to have a centralized series of "build commands", for lack of a better term that can perform those actions in addition to whatever is contained within the rezbuild.py. This way, we can set up in a central location that these configuration files, if they exist, should be modified on rez-release, so that TDs managing their rezbuild files don't have to put the same logic in every rezbuild.py file.

One solution I've toyed with is creating a custom build plugin for our studio. Is this the correct approach? Curious to hear what others think or have done.

TL;DR, I'm trying to reduce the amount of redundant code that needs to be present in each package's rezbuild.py to keep things simple, and also to make sure that individual TDs, with less knowledge of Rez and our pipeline, has less of a chance of improperly implementing the build process.

[Fede Naum]

Hi Benjamin, 

Probably not answering to your question, but this is our approach.

We do not use bez, but instead, we use cmake to build our python packages as well. 

We created  a macro in cmake, and the all the python rez packages use the same macro in the CMakeLists.txt.  

TD's basically just copy paste that the CMakeLists.txt with that one line macro and that gives them a target to run the test, get coverage, pylint and other python dependency checks for free.

Cheers

Fede

[Allan Johns]

Hey Benjamin,

Is there a particular reason you can't simply put common build code into a package (eg: build_utils), which you then include as a private_build_requires?

This is not uncommon, for example at my studio we have a qt_build_utils package that provides cmake macros for building .py files from .ui at build time. You can easily do the same to provide common python build code, which your rezbuild.py would then utilize.

Hth

A

ps - Try to use the new build_command feature rather than bez, which I'd like to deprecate in future. It's straightforward to switch from one to the other: https://groups.google.com/forum/#!topic/rez-config/d766K7gZOUs

--
You received this message because you are subscribed to the Google Groups "rez-config" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rez-config+unsubscribe@googlegroups.com.
To post to this group, send email to rez-c...@googlegroups.com.
Visit this group at https://groups.google.com/group/rez-config.
For more options, visit https://groups.google.com/d/optout.

[Benjamin Rhoades]

Great suggestion, Allan. I hadn't considered doing it that way.

Also, thanks for the heads up about build_command. I hadn't realized that you were trying to phase out Bez.

To unsubscribe from this group and stop receiving emails from it, send an email to rez-config+...@googlegroups.com.