rez-build and platform

698 views
Skip to first unread message

Fredrik Brännbacka

unread,
Mar 14, 2016, 11:04:19 AM3/14/16
to rez-config
When doing a rez-build -i -p /package_path
With a package.py looking something like:

####
name = 'test'

version = '1.0.0'
variants = [
    ['platform']
]
####

it installs to /package_path/test/1.0.0/platform
Shouldn't  it resolve to: /package_path/test/1.0.0/platform-[linux,osx] depending on the platform package.

I want to be able to build my package on different platforms to the same path and end up with:
/package_path/test/1.0.0/platform-linux/built files
/package_path/test/1.0.0/platform-osx/built files

What am i missing?

Cheers
/Fredrik

Allan Johns

unread,
Mar 14, 2016, 1:16:00 PM3/14/16
to rez-c...@googlegroups.com
Hey Frederik,

Variants don't work like that in builds. If you want a package with linux and osx variants, your package.py should contain:

varaints = [
  ["platform-linux"],
  ["platform-osx"]
]

Same goes with variants based on other packages (python etc), there's no difference. If you wanted a python-2.6/2.7 pair of variants, you'd list them explicitly. Variants are always explicit, they are not created for you.

An issue at the moment is that you won't be able to perform a full cross-platform build in one rez-build command, because there's not yet support for a remote build process (which would dispatch the build for each variant to some host associated with package(s) in that variant). However in the meantime you can just ssh to the relevant host and perform a build using the -v option (--variant). Performing these separate builds will still install into the same package - the variants are merged into the resulting package.py for you.

Hth
A




--
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+...@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.

Fredrik Brännbacka

unread,
Mar 14, 2016, 1:27:11 PM3/14/16
to rez-c...@googlegroups.com
Thanks. That makes sense.
If I list the different platform variants i get build error because platform-osx doesn't exist on Linux. And that makes sense and I have to specify the correct variant. What I want is something like [["platform-%s" % (current_platform)]]. So I don't need to care what platform I'm building on.

Is this possible right now? Do you think it is a concept worth exploring?

Cheers
/Fredrik
You received this message because you are subscribed to a topic in the Google Groups "rez-config" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rez-config/xE0w4SSlAMg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rez-config+...@googlegroups.com.

Allan Johns

unread,
Mar 14, 2016, 1:41:46 PM3/14/16
to rez-c...@googlegroups.com
Hey Frederik,

That would be possible to add yes - at the moment there are only objects bound to the python namespace that the package.py is executed in, when commands() is run (eg 'env', 'root' etc). In principal there wouldn't be a problem exposing some of these for all attributes - there's one called 'system' for example, so you would use system.platform.

But I would hesitate to go down this road. I think it's better if your package definition is explicit. In your example above, how do I know that your package works for linux and osx, but not for Windows, for example?

What rez-build *should* do is have an option to skip over variants that cannot be met (package doesn't exist) or that conflict with the current implicit package list (most times this would mean that the variant platform doesn't match the current). Then you could just rez-build over your linux and osx variants, and just the linux variant would build.

This would be a fairly small addition and something I've been planning to do for some time. Does that sound like it would solve your issue?

Thanks,
Allan




Fredrik Brännbacka

unread,
Mar 14, 2016, 1:45:01 PM3/14/16
to rez-c...@googlegroups.com
I think I would prefer a silent skipping if the requirement is not met. Maybe even by a flag.

Thanks
/Fredrik

Jonathan Gibbs

unread,
Jun 22, 2018, 3:13:49 PM6/22/18
to rez-config
I know this is a very old thread. Did this ever happen?

I'd love to be able to say "rez-build --only-variants-for-this-platform".

Allan Johns

unread,
Jun 22, 2018, 6:27:04 PM6/22/18
to rez-c...@googlegroups.com
So, there are two parts to this.

The first part has been addressed - that is, the ability to be less specific about requirements at build time, and have the requirements hardened in install/release. See: https://github.com/nerdvegas/rez/wiki/Package-Definition-Guide#requirements-expansion

So you can go:


name = 'test'

version = '1.0.0'
variants = [
    ['platform-*']
]

The second part is the ability to restrict the build to only those matching current platform, and that hasn't been done yet. It won't be difficult to implement though. You can get around this manually with rez-build currently, by using the --variants flag, but that flag is not present in rez-release (the first thing I would do is add this to rez-release in fact).

So I think it's just a matter of adding a new rez-build/rez-release flag to only build those variants that don't conflict with the current implicit package list, perhaps we call this '--skip-conflicting-variants', or '--skip' for short.

A




--
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.

Allan Johns

unread,
Jun 22, 2018, 6:28:50 PM6/22/18
to rez-c...@googlegroups.com
Actually, you can't use requirements expansion for variants how I've shown here, but it's still possible to do. See the docs - you just have to explicitly use the 'expand_requires' function, and implement as an early binding attribute.

Hth
A

Blazej Floch

unread,
Jul 26, 2018, 10:53:51 AM7/26/18
to rez-config
Good to learn about requirement expansion.

Btw. rez-release does have a --variants flag, we rely on it for some time.

We have a very low tech solution for these kind of problems.
First I've implemented a small script called 'lsvar' that shows you the indices of the package.py in cwd:

package.py variants for usd-0.8.5a:
-------------------------------------------------

 
0: platform-linux  arch-x86_64  os-CentOS-7.2  python-2.7    boost-1.61  tbb-4.4    pyside-1.2.2  pysidetools  
 
1: platform-linux  arch-x86_64  os-CentOS-7.2  maya-2018     boost-1.61  mayasetup
 
2: platform-linux  arch-x86_64  os-CentOS-7.2  katana-3      boost-1.61  
 
3: platform-linux  arch-x86_64  os-CentOS-7.2  houdini-16.5  boost-1.61  !maya

This helps finding the right index. From there we just pipe it into --variants.
It also can show released variants only (using rez-search). Maybe something we can contribute back if you find it valuable.

Then we bootstrapped releasing as a build_process called 'ssh' that would build locally if your platform matches the variants platform/os or else lookup a global table of hosts and ssh and build/release from there. It can skip not existing variants and generates a log at the end.

Since it relies on ssh it does not work with windows well but at least we can build on various distros without much overhead.
This made migration of distros quite bearable.

Ideally we want to go back to a dedicated build server that would do the right thing: split variants to clients with matching os/platforms. But windows is a minor platform here anyway so we just manually release our way through.
To unsubscribe from this group and stop receiving emails from it, send an email to rez-config+...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages