[Slackbuilds-users] Setting options
chris.willing at iinet.net.au
Sun May 31 00:41:08 UTC 2015
On 29/05/15 17:35, Leonard Schmidt wrote:
> 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"
>> 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.
I'm not proposing any changes to the way we handle SlackBuilds from
SlackBuilds.org - from my earlier post:
> I've had an idea about it which I'll outline here and ask for any comments - its _not_ a proposal for any change at SBo.
My intention was to suggest a general method to handle the setting of
options _locally_ i.e. by the person building packages, and ask for
comments on that method. I assumed people would suggest alternatives
that I could think about and you did that, thank you.
In fact I've since made a three line change to my build tool to do the
job by processing a new ENVOPTS field which I've added to my local .info
files, where needed; it looks something like:
ENVOPTS="ASS=yes BLURAY=yes ... ILBC=no ..."
much like your .env files. The build tool just reads the field and
exports each element into the environment before running the
.SlackBuild. I works very well so far.
Thanks again for your input.
More information about the SlackBuilds-users