Make options lists instead of strings and make -append more magical

[Ryan Schmidt]

Options like configure.args or depends_lib seem in a way magical because of the convenience methods MacPorts makes available, but they're not as magical as they could be.

We use commands like configure.args-append to add to options, and this makes us feel like options are lists or arrays, but in fact, they're just strings. The implementation of handle_option-append is quite simple: it just uses Tcl's built-in concat procedure, which trims leading and trailing whitespace and combines items with a single space. This has undesirable consequences when the option in question needs a different type of concatenation.

For example, consider configure.pkg_config_path. Using "configure.pkg_config_path-append foo" will append a space and "foo" to configure.pkg_config_path, but in fact, pkg_config_path needs to be colon-separated, not space-separated. So it becomes incumbent upon each maintainer to remember that and to never use configure.pkg_config_path-append, and rather to manually concatenate onto it using a colon. I'd rather not make maintainers have to remember that kind of detail.

Or, consider notes. Notes are supposed to be paragraphs of text. A port might define a paragraph or two of notes, then want to provide additional notes conditionally, perhaps in a variant. We tend to want to separate paragraphs of text by two newlines. But if a port uses "notes-append foo" then only a single space and "foo" will be appended to the existing notes. There's no way around this: even something like "notes-append "\n\nfoo"" doesn't work because concat trims the leading whitespace.

I wonder how feasible it would be to treat options as lists instead of strings, and then teach MacPorts to use different concatenation values depending on which option it is. notes could be concat'd with "\n\n", configure.pkg_config_path could be concat'd with ":", if we had a configure.path it could be concat'd with ":", and " " could be used for others.

Trying to include options within a portfile has also been problematic. For example sometimes I seem to have to use join or eval to get things to work without Tcl inserting incorrect escaping. Would be lovely if we could make this process more transparent and straightforward. For example, perhaps the hypothetical base procedure that would perform this concatenation could be exported for portfiles to use when needed.