[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Andreas Fuchs
Subject: bug#42761: 28.0.50; [feature/native-comp] allow customizing command line/driver options?
Date: Thu, 20 Aug 2020 10:12:54 -0400

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]