On 04 Nov 2013, at 20:15, Ward Poelmans wrote: > On Mon, Nov 4, 2013 at 6:35 PM, Fotis Georgatos <[email protected]> wrote: >> * toolchain-less builds; important for debuggers, performance tools and all >> non-ABI exposing software > > +1
Are you asking for easyconfigs that use a dummy toolchain? I'm OK with merging them in, if PRs are issued for them. This fits in the minimal-vs-full toolchain discussion, see also https://github.com/hpcugent/easybuild-wiki/pull/11 . I'm not sure if there's anything to discuss here. It's not like we oppose dummy-toolchain easyconfigs, we just don't think it's a good idea (which doesn't mean we're not willing of merging them in). To also make them used by existing easyconfigs, we probably need https://github.com/hpcugent/easybuild-framework/issues/741 to be tackled first. That would give everyone the freedom to go for one of both schemes (with dummy toolchain builds to be an extreme case of minimal toolchains). > >> * module statistics! # how to record module usage; what do you do? > > Is this something for EB? I would think it's more something to > implement in lmod? +1, this is outside of EB imho > >> * Inform upstream developers of patch effort, add REF. with tracking URL >> within patch files > > +1, I usually push patches upstream but something to add tracking > would be useful. I also try to get patch files documented when they're added in PRs, i.e. a reference + useful comment at the top. Pushing them back is important too, but costs time, and is sometimes not worth the effort (i.e. they don't get accepted, etc.). > >> * diverse build regtest environment, ensure multiple OSes/archs/distros >> tested > > Isn't this something that a bunch of vm's would solve? This is a more long-term goal imho, probably too early to discuss that in today's conf call (also, there's no issue on this). It would be very useful though, but would require quite a bit of work on the side to coordinate things. Maybe we (HPC-UGent) should try and set something up with Fotis (Uni.lu) first, and then use that as a learning experience. One of the first things that would be required is making --job more portable, e.g. by kicking out the pbs-python dependency (which is half-broken anyway) and just use the qsub command directly (or the alternative command for other resource managers like OAR). Fotis: let's open an issue for this and look into this in the coming months, gradually. regards, Kenneth
