bug#42761: 28.0.50; [feature/native-comp] allow customizing command line/driver options?

[Andreas Fuchs <asf@boinkor.net>]

[-- Attachment #1: Type: text/plain, Size: 1557 bytes --]

On Wed, Aug 19, 2020 at 11:41 AM Andrea Corallo <akrl@sdf.org> wrote:

> Okay if the libgccjit feature is not available we raise an error, but
> how the user is supposed to test for this feature without compiling?
>
> 'comp-libgccjit-version' starts working only if gcc_jit_version_major is
> available otherwise return nil, and I added gcc_jit_version_major into
> GCC10 :/
>
> We need to offer a way to the user to check for that before going for
> compilation.  The only idea I've at the moment is that we expose a
> function to set these instead of using 'comp-native-driver-options'.
>

Ah! That's a good point about users being unable to tell if their options
will work until they try to compile.

I would like to keep the driver-option setting interface as a variable
holding a list, as that still allows users to edit them with the
emacs-provided functions to do so. With a function accessor, we'd have to
add functions to add/remove/map over/etc the options, which emacs already
provides with `add-to-list' and friends.

I think we could expose a predicate
`comp-native-driver-options-available-p' that'll return t if the necessary
facility exists.

For some extra credit, maybe we could even have that predicate test whether
a given set of driver options has a chance of succeeding (I guess that this
would have to attempt a no-op compile to exercise the compiler->linker
chain). A predicate to test for compatibility would be the nicest and would
fit the bill well, though.

-- 
Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs

[-- Attachment #2: Type: text/html, Size: 2132 bytes --]