As it's a quite big change in recipe specs I'm not commiting this until the rest of the Compile tools are considered stable, so we can make a release quite soon after the commit. This to prevent the new recipe type to be created by the new tools, before there is a stable release.On 8/3/06, Jonas Karlsson <[EMAIL PROTECTED]> wrote: <[EMAIL PROTECTED]>> On 8/3/06, Dan <[EMAIL PROTECTED]> wrote: >> That's a really good question. Unless someone has an objection, I >> also vote for >> >> recipe_type=autoconf > > I don't have a definite vote for this, but I'd be leaning between > autoconf or autotools. >Yes, autotools were among my alternatives but I thought that autoconf werebetter and beat the former.Lucas has a good point about non-autoconf configure scripts that are currently supported, though. That made me think about using configure again.
I've attached a generated patch for the changes I have made, so that you can review them. I have named the compileprogram type to configure, while until we decide on the name.
The changes, in short: Compile: * changed types from is_<type>=yes to recipe_type=<type> * added a backward-compability section * changed type compileprogram to configure NewVersion: * added a sed line to convert is_<type>=yes to recipe_type=<type> * added a sed line to convert type compileprogram to configure MakeRecipe: * changed types from is_<type>=yes to recipe_type=<type> * changed type compileprogram to configure RecipeLint: * Made it check if $recipe_type is set instead of $is_<type> * Made it give an WARN if the type is declarated in the old style * Some changes to adapt to the new recipe type spec. -- /Jonas Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
recipe_type.patch
Description: Binary data
_______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
