#35897: Add a buildbot with +universal for all packages -------------------------------------+-------------------------------- Reporter: mojca.miklavec.lists@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Low | Milestone: Component: contrib | Version: Resolution: | Keywords: Port: mp-buildbot buildbot | -------------------------------------+-------------------------------- Changes (by mojca@…): * cc: ryandesign@…, cal@…, raimue@… (added) * port: mpab => mp-buildbot buildbot Old description:
It would be sooooooo great if packages like qt4-mac and compilers like clang-3.2 would be built with +universal along the normal variants.
I would like to request either: * to add a keyword to portfiles to signal to builtbot the desire to build a certain package and its dependencies with +universal (useful for qt4-mac, developers could add the flag to commonly used ports and those that require longest build times) * or simply compile all packages with +universal
New description: It would be sooooooo great if packages like qt4-mac and compilers like clang would be built with +universal along the normal variants. I would like to request either: * to add a keyword to portfiles to signal to builtbot the desire to build a certain package and its dependencies with +universal (useful for qt4-mac, developers could add the flag to commonly used ports and those that require longest build times) * or simply compile all packages with +universal -- Comment: Now that the build scripts have been reimplemented, deployed on a new hardware and with a new sysadmin), this finally sounds doable to me without the need for any additional virtual machines for the build slaves. Ryan's idea was to automatically upload archives of `+universal` ports only when a package like `wine` asks for `i386` or `universal`. In fact this is already working, so the ticket about "building `+universal`" could be closed as `fixed` as far as I'm concerned. I'm not sure what the situation is with VirtualBox. Has i386 been "disabled" just because it was annoying to compile all the dependencies from source? If that's the case, the universal builds could probably be enabled again. Some additional builds of `+universal` build tools (`ld`, `clang++`, ...) might be handy for older OSes (10.5 in particular; but we currently don't provide that one). We could in principle build all the ports as `+universal` with a few additional lines of code (and by consuming approximately three times the resources we currently do), but maybe we should go with the current approach for now and see whether there is any need to add additional candidates for universal builds later on. As far as `+quartz` is concerned: I started implementing preliminary support to build with additional variants. I will need some help extending the script that is currently responsible for installing dependencies (`portname +quartz` usually needs different dependencies than `portname +x11`), but once that gets fixed, it would enable manual builds with arbitrary variants for now (which we shouldn't start misusing). Once that is in place, we could start implementing some heuristics to determine when to build a port with additional variants (either some hardcoded list of ports or all ports that provide a non-default `+quartz` variant etc.). The nice thing about the current buildbot setup is that we don't need any additional resources (other than some extra disk space and CPU clocks on existing infrastructure) to achieve that. -- Ticket URL: <https://trac.macports.org/ticket/35897#comment:14> MacPorts <https://www.macports.org/> Ports system for OS X