automating menu options in ports (and other ports build questions)

[Polytropon]

On Thu, 24 May 2012 19:28:58 -0600, Gary Aitken wrote:
> 1. When building a port, the system uses sysinstall to set options for 
> the build. 

No. The default options are set by the port maintainer, usually
in the port's Makefile.



> How does one configure those options so make can be run 
> unattended? 

You can use two approaches:

a) Use "make config" or "make config-recursive" to to select
   all choices "in one rush", then start building.

b) Use a port management tool to do what the commands under a)
   would do. For example, "portmaster --force-config" would do
   so. You can also use the port mangement tool's configuration
   file to store port-specific selections in a file. There's
   support for this "batch operation" style of working to avoid
   interaction.



> I didn't see anything in the ports documentation, but maybe 
> I'm blind. 

Check "man 7 ports".



> In particular, how does one configure a dependent port for 
> the options you want whenever it is built as part of a higher-level build?

The "-recursive" targets ("make config-recursive et al.) do this.



> 2. Do port builds deal with concurrency?
> i.e. can I safely do a make install in two different ports subtrees 
> simultaneously?

I think this highly depends. As soon as you _know_ there will be
no "same dependency" occuring, it should be no problem. To avoid
this, each port (and the dependencies it needs) could be build
in a separate tree, but that could also mean doubled builds; it
would also not fully solve the problem of concurrent installations.
See the meaning of "building dependencies" and "run dependencies"
which both tend to be installed to the (same!) system in order to
be usable by the successive port building.



> 3. Do the package builds use the defaults set in the ports tree?  If 
> not, how are the options for packages chosen, and how does one determine 
> what the package options are?

They use the default options.



> 4. Is there a discussion anywhere of whether or not one should turn on 
> various optimizations? 

Depends. For example, if you want to make mplayer run on older
systems, you will surely use some optimization and customization.
You will also do so if you want all the codecs.

Maybe some of the reasons why some options aren't set by default
(and therefore not present in the automatically built packages)
is patent-lawyer-intellectual-property-blah-pirate-blah stuff,
especially because it's illegal to listen to MP3 in the U. S. :-)



> If these aren't turned on by default, but are 
> safe, why aren't they the default? 

Maybe because there is no "general use benefit" in them? Not sure.
See also explaination above.



> Is this a cross-platform build 
> issue, and the default is to build for cross-platform?

The ports tree is, if I interpret that correctly, platform-independent.
So the selected options should be "best choice" for all supported
platforms (and there's some selective logic in the port building
infrastructure itself as well as in some of the Makefiles).



> 5. It looks like the options which show up using sysinstall are from the 
> OPTIONS variable in the Makefile. 

Excuse me, where exactly do you see compile-time options in the
sysinstall program? I know it can select and install packages,
but PORTS?



> Is there any convention for where to 
> find out more about the option other than the often useless text hint 
> provided in the menu?
>    e.g. gvfs has an option called
>           FUSE       Enable fuse
> which doesn't say which of the several software systems called FUSE this 
> refers to
>    e.g.  OPENGL      Use OpenGL graphics
> doesn't say much about why you would want to do that,
> what the opengl option actually does, ramifications,
> whether it will help only if your graphics card / driver supports it,
> etc.

Ha, good question! :-)

If you deal with ports, it's often useful to have a second
system / terminal / computer / ... with a web browser so you
can try to look up the meaning of options. If you don't have
that, making a selection can be hard:

+--------------------------------------------------------------------+
|                     Options for stupido 19.84                      |
| +----------------------------------------------------------------+ |
| | [ ] CUPS         Enable support for printing (requires CUPS)   | |
| | [ ] GTK          Use GTK backend                               | |
| | [ ] KDE4         Use KDE4 backend in room 101                  | |
| | [ ] FUSE         Enable FUSE                                   | |
| | [ ] OPENGL       Use OpenGL graphics                           | |
| | [ ] KLOMPATSH    Use Klompatsh                                 | |
| | [ ] RHUMBOIRE    Use RHUMBOIRE backend                         | |
| | [ ] QUEEKNARG    Enable QUEEKNARG support                      | |
| | [ ] ECK'N'POOT   Build with COM-POO-TAIR module                | |
| | [ ] SHMEER       Build bindings for Shmeer and Shmeerlappen    | |
| | [ ] SHLORTS      Enable support for SHLORTS (requires GNOOLFS) | |
| | [x]              Use nothing, go away.                         | |
+-+----------------------------------------------------------------+-+
|                       [  OK  ]       Cancel                        |
+--------------------------------------------------------------------+

I soon expect the mentioned "programs" to pop up in reality. :-)



>    Or is this a documentation project in the offing?

I would welcome a kind of text file that lists all the strange
names with a short description of what they are and what you
need them for, being more informative than the short "one liners"
in the options dialog.



-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...