Hello, Christoph Willing writes: > >Using that same idea, of adding to the local version of the .info file, >why not add an OPTIONS field? Probably better might be OPTIONS_ON and >OPTIONS_OFF fields e.g. > OPTIONS_ON="ASS BLURAY CELT DC1394 FAAC FREI0R" > OPTIONS_OFF="ILBC" >which the build tool would use to set options in the environment when it >runs the SlackBuild.
I don't know if I misunderstand you, but if with build tool you mean your own solution, I don't see why you can't just as well add support for `option handling' to your tool. I found compiling ffmpeg with my desired dependencies tiresome, too, so my tool now is aware of .deps (and .env) files I put into ~./script/options. The format is dep:VAR=VAL (or simply dep) for .deps files, this will get picked up automatically if I don't deactivate dependency handling. (In case of mpv, for example, I override NUMJOBS via mpv.env to only contain an integer, no -j option, otherwise it complains.) The upside is that I can save these files and use them on other machines easily, and no additional field in .info files is needed. If I recall correctly, slackrepo also has (more powerful) so-called hintfiles, and Karel Venken's `getpkgs' also has support for a HINTS file, but I have little experience with these tools. No offense, but I think people compiling SlackBuilds by hand know that it won't be convenient, and those who use (their own) tools have the ability to specify additional dependencies via their build tool, at least theoretically. As long as additional dependencies are listed in README, I see no reason for any big changes in the way we handle SlackBuilds from SlackBuilds.org. Regards Leonard _______________________________________________ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/