Hi Greg,
Hello Björn,
This would be great! I'm not sure about the type attribute - <action type="cheetah_command" may be ok, but maybe a more generic type like <action type="template_command" would be better. I'm not quite sure, so go with what you feel is best.
I come up with the following: <action type="template_command"> #if env.get('X11_LIB_DIR', False) and env.get('X11_INCLUDE_DIR', False): ./configure --prefix=$env.INSTALL_DIR --x-includes= $env.X11_INCLUDE_DIR --x-libraries=$env.X11_LIB_DIR #else: ./configure --prefix=$env.INSTALL_DIR #end if </action> $env is the global access point to the env variables and its working fine for the few repositories I tested it. I had hoped to get it a little bit prettier but fabric and cheetah doesn't work well together. If that is still satisfying I would clean up my code and create a pull request [1]. What do you think? Cheers, Bjoern [1] or patch, I heard rumours that you do not like pull requests ;)?
Thanks for looking into this!
Greg Von Kuster
On Jul 7, 2013, at 5:50 AM, Björn Grüning <bjoern.gruening@pharmazie.uni-freiburg.de> wrote:
Hi,
I was thinking how to tackle the build failures like the atlas library on OS-X or the ones from xlib and ease the writing of the shell_command a little bit.
Dave B did some fancy shell scripting in 'package_emboss_5_0_0' and I was also sometimes forced to use some bash tricks.
What about to make that more easy and powerful, and as a plus more consistent with the tool-command tag, and use cheetah for that kind of work.
Something like that could work easily:
#if ${os.environ}.getVar('X11_LIB_DIR', None): ./configure ... --x-includes=.... #else: ./configure #end if
Also we could define some reserved variables like $__is64__ and cheetah evaluate that. $INSTALL_DIR and $REPOSITORY_DIR can also be a cheetah variable and we do not need to replace it later manually.
What do you think any comments? If no one has any objections I can try to implement an <action type="cheetah_command">.
Thanks, Björn