Feat/basic cmake python linux #2
Conversation
| env.PATH.prepend("{this.root}/bin") | ||
|
|
||
| tests = { | ||
| "version_check": 'echo [[ \\"$(cmake --version | head -n 1)\\" -eq \\"cmake version {version}\\" ]]'.format(version=version()) |
There was a problem hiding this comment.
I would put the equivalent of this directly into version() instead, may as well abort early if there's a mismatch
| } | ||
|
|
||
| with scope('config') as config: | ||
| config.release_packages_path = '${SW_EXTERNAL_RELEASE_ROOT}' |
There was a problem hiding this comment.
why have this? User can already provide their own rezconfig.py as per README.md instructions
There was a problem hiding this comment.
I think we should go the way of batteries-included with respect to demonstrating multiple package-repository usage.
Ideally, I'd like to achieve something where specifying "external" / "internal" vendor_type automatically changes the release path.
| @@ -0,0 +1,130 @@ | |||
| #!/usr/bin/env python | |||
There was a problem hiding this comment.
So let's think about this as setting up the standard for what most of our build scripts are gonna look like. I think there's opportunity here for removing lots of redundancy. I propose:
- we add our own
build_utilspackage that gets built before anything else. Simple, pure python, no deps. - We put reusable stuff like BuildConfig class in here
- having formatted cmake code embedded into py code isn't that easy to read. What if we had that code stored in a CMakeLists.txt.j2 file, and used Jinja2? I know that introduces another build-time dep, but damn if this wouldn't look a bit like ansible, and would help keep things pretty clean.
There was a problem hiding this comment.
I agree completely, however:
getting cmake and python built are two builds where some redundancy can be permitted because we're going to rely on them to build all the other packages, so we get a little bit chicken-egg-y. It depends on whether we want to allow the system-python-interpreter to be used as a bootstrapping dependency. What are your feelings there?
regarding templatizing cmakelists, I don't yet really see the value, but it's something we can move towards. For now, I'd like to target linux-build-ability, while we consider the best to provide multi-platform / multi-arch / multi-OS support, because we have some logistics issues there. For example, I think the best thing to do WRT to "platform-specific build flags" is to externalize the config from the build and load according to some dict-merge type of system, but what should that look like? I'm a little worried it'll end up looking like qt's 'mkspecs'
even more important is somehow expressing to the package.py which platforms/archs/os's it supports, so that a rez-install actually works when a given platform config is given.
|
|
||
| build_requires_source = True | ||
| build_requires_internet = False | ||
| build_requires_sudo = False |
There was a problem hiding this comment.
might wanna drop these from the installed pkg def, prefix with __ to do that, as per https://github.com/nerdvegas/rez/wiki/Package-Definition-Guide#package-attributes
There was a problem hiding this comment.
I'd think people might want to rez-search these attributes in the future in their installed packages, so as to be able to identify builds that use sudo, for example, and try to fix them to make them not require it.
These should be a helpful basis to start from, even if we're effectively blocking off windows support with symlink usage for now.