On Thu, 5 Mar 2015 at 12:26 -0000, Jens Timmerman wrote: > > > Just to clarify: the easyconfigs that are part of the EasyBuild > > > installation are meant to be treated as examples (which does not > > > mean they should contain inconsistencies like the one you > > > reported).
> > This is also where I find the current easybuild process a little > > awkward. I generally prefer examples to be out of the main > > execution path. i.e. If these are really examples, they should > > not be used automatically. > They are not, you need to provide -r before they will be picked up. > and people have actually complained about having to provide -r every > time. You are right. I'm still working out what my workflow will be. It looks like I will end up with a complete set of files copied out of the distributed easyconfigs. So far I've had little changes to about half of the configs (mostly bring things to a consistent version). > > If they are a default configuration, they should work and be > > maintained (which is a lot of work for 2000+ configurations). > We actually build every single easyconfig before every release, yes, > this is a lot of work, and we are aware that it's not because it's > working on our system it will work everywhere. And you are > completely free (and able to) deviate from them. Another thing I've needed to do is adjust the download information on a few of them. I suspect you are getting the distfiles from a local cache (just like I'm building a local cache of distfiles). A few distfiles are known to require a manual download. It might be nice for easybuild to better mark these in the easyconfig blocks and maybe emit a clearer message when a manual download is suspected due to the marking. > > I presume this can be addressed by not installing the easyconfig > > package, but I would still like to have the examples handy for > > reference. > They are also there so you don't need to replicate all the work > someone else has already done. I think Kenenths main point was that > you should not be afraid to make a change in an easyconfig if it > beter suits your local needs. I'm looking forward to 2.0 and will get a chance to see how I deal with finding and applying any improvements between the updated easyconfig files and my modified/copied versions. I'm probably gratuitously changing things that would be better not changed. > This is different for EasyBlocks, if you need to make a change > there, we really want to know about it, because probably everybody > using EasyBuild will benefit from it, whereas changes in easyconfigs > will in general only apply to a small subset of people. So far I have not needed to look at those at all. > > I'm still getting used to the log files and am finding some issues > > in their usability, but that is subject for a separate discussing > > at another time. > some tips about understanding the logfiles are provider here: > http://easybuild.readthedocs.org/en/latest/Logfiles.html Probably the biggest thing I'm not easily seeing in the log files is the module name at each of the major steps. The page above talks about searching for '_step' as a way to find important things and that work well, but when I'm robot building 20+ modules it seems to take me more work than necessary to figure out which module the step is referring to. Adding the .eb filename or the module name to each of the "_step" messages would be very helpful. Having a tag a little more explicit than "_step" might also be useful. On occasion the log files are full of other strings just matching _step. '^==.*_step' does work fairly well as a search string, but is a little more complex to type. I tend to use the --logtostdout option to get more complete logs. On other package building systems I like to be able to see the log output as it is being generated. easybuild seems to accumulate this somewhere I haven't been able to easily find and only emit it at the end of a step. When compiling something that takes 15+ minutes (gcc, perl, python, boost, etc) I like to see progress as it happens. Stuart -- I've never been lost; I was once bewildered for three days, but never lost! -- Daniel Boone
