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

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

[Andreas Fuchs]

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

I'm trying out emacs with native-comp on nix (working on this branch
here: https://github.com/NixOS/nixpkgs/pull/94637), and am stumbling
over a problem that is pretty specific to nix, it seems: As nix isolates
each package to a "store" directory, you have to set specific linker
flags so that gcc-jit can find -lgccjit and -lgcc_ext. This is currently
done via the $LIBRARY_PATH environment variable, which works but seems
pretty hackish to me (least of all because it isn't a thing that's
supported on the darwin cctools linker - there, you have to pass the
linker path as command-line arguments).

I feel like it would be much better if users could specify the gcc
driver flags directly, via gcc_jit_context_add_driver_option
(
https://gcc.gnu.org/onlinedocs/jit/topics/contexts.html#c.gcc_jit_context_add_driver_option
).

That way, instead of overriding environment variables which might get
reset in child processes' wrapper scripts, an emacs installation could
more directly influence the compilation step.

Thanks,
Andreas.



In GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin19.6.0, NS appkit-1894.60
Version 10.15.6 (Build 19G73))
Repository revision: 80d7f710f2fab902e46aa3fddb8e1c1795420af3
Repository branch: master
Windowing system distributor 'Apple', version 10.3.1894
System Description: Mac OS X 10.15.6

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
'configure
--prefix=/nix/store/2j5mwh18mqpri4k1v0j05gkklyp79rvr-emacs-gcc-20200802.0
--disable-build-details --with-modules --with-ns
--disable-ns-self-contained --with-nativecomp
CFLAGS=-DMAC_OS_X_VERSION_MAX_ALLOWED=101200'

Configured features:
JPEG TIFF PNG RSVG GLIB NOTIFY KQUEUE ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS NS MODULES NATIVE_COMP THREADS JSON PDUMPER

Important settings:
value of $LC_ALL: en_US.UTF-8
value of $LC_COLLATE: C
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
buffer-read-only: t
line-number-mode: t
transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml easymenu mml-sec password-cache epa derived epg epg-config
gnus-util rmail rmail-loaddefs text-property-search mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date
subr-x cl-loaddefs cl-lib seq byte-opt gv bytecomp byte-compile cconv
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel term/ns-win ns-win ucs-normalize mule-util term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
tab-bar menu-bar rfn-eshadow isearch timer select scroll-bar mouse
jit-lock font-lock syntax facemenu font-core term/tty-colors frame
minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite charscript charprop case-table epa-hook jka-cmpr-hook help
simple abbrev obarray cl-preloaded nadvice loaddefs button faces
cus-face pcase macroexp files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote threads kqueue cocoa ns multi-tty make-network-process emacs)

Memory information:
((conses 16 53347 6820)
(symbols 48 6006 0)
(strings 32 15710 2115)
(string-bytes 1 557531)
(vectors 16 9810)
(vector-slots 8 193576 7914)
(floats 8 20 24)
(intervals 56 194 3)
(buffers 992 12))

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

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

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

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Andreas Fuchs <asf@boinkor.net> writes:

> I'm trying out emacs with native-comp on nix (working on this branch
> here: https://github.com/NixOS/nixpkgs/pull/94637), and am stumbling
> over a problem that is pretty specific to nix, it seems: As nix
> isolates
> each package to a "store" directory, you have to set specific linker
> flags so that gcc-jit can find -lgccjit and -lgcc_ext. This is
> currently
> done via the $LIBRARY_PATH environment variable, which works but
> seems
> pretty hackish to me (least of all because it isn't a thing that's
> supported on the darwin cctools linker - there, you have to pass the
> linker path as command-line arguments).
>
> I feel like it would be much better if users could specify the gcc
> driver flags directly, via gcc_jit_context_add_driver_option
> (https://gcc.gnu.org/onlinedocs/jit/topics/contexts.html#
> c.gcc_jit_context_add_driver_option).
>
> That way, instead of overriding environment variables which might get
> reset in child processes' wrapper scripts, an emacs installation
> could
> more directly influence the compilation step.

Hi Andreas,

I don't think should be too difficult to expose the driver option.  The
downside is that gcc_jit_context_add_driver_option is not available in
all libgccjits (IIRC I added it to GCC 9).

Another option would be to set our self the LIBRARY_PATH before invoking
the compiler only in the async process.  Have you already tried using
`comp-async-env-modifier-form' for this?

Thanks

  Andrea

-- 
akrl@sdf.org

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

[Andreas Fuchs]

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

Hi Andrea,

Thanks for the quick reply!

On Sat, Aug 8, 2020 at 2:30 PM Andrea Corallo <akrl@sdf.org> wrote:
>
> Andreas Fuchs <asf@boinkor.net> writes:
> > I feel like it would be much better if users could specify the gcc
> > driver flags directly, via gcc_jit_context_add_driver_option
> > (https://gcc.gnu.org/onlinedocs/jit/topics/contexts.html#
> > c.gcc_jit_context_add_driver_option).
> >
> > That way, instead of overriding environment variables which might get
> > reset in child processes' wrapper scripts, an emacs installation
> > could
> > more directly influence the compilation step.
>
> Hi Andreas,
>
> I don't think should be too difficult to expose the driver option.  The
> downside is that gcc_jit_context_add_driver_option is not available in
> all libgccjits (IIRC I added it to GCC 9).

That makes sense. Assuming that ~everyone would build the native-comp
branch with a recent (>=9) gcc release, I cut a branch here that
implements this (it does pass the driver options, too!):
https://github.com/antifuchs/emacs/compare/allow-setting-driver-options

I think this behavior could be made conditional on the presence of the
correct libgccjit ABI version, by declaring the variable in C code,
and then everyone on a newer gcc would be able to reap the benefits,
and everyone else could still use the branch, but only with the
standard linker flags as before (or passing LIBRARY_PATH if that's
supported on their platform).

> Another option would be to set our self the LIBRARY_PATH before invoking
> the compiler only in the async process.  Have you already tried using
> `comp-async-env-modifier-form' for this?


LIBRARY_PATH does work on GNU binutils: the concern for my nixpkgs
branch is for usage on Darwin, where that environment variable doesn't
do anything. To get anywhere there, we have to have a way to pass
command-line arguments... /-:

Besides that though, I think it might be useful for folks who want to
specify that other linkers should be used (like gold or lld), or
passing a -specs argument... I don't know if that's supported at all
yet, but adding this option would be an easy way of finding out how
unsupported it is (-;

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

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

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

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Andreas Fuchs <asf@boinkor.net> writes:

> That makes sense. Assuming that ~everyone would build the native-comp
> branch with a recent (>=9) gcc release, I cut a branch here that
> implements this (it does pass the driver options, too!):
> https://github.com/antifuchs/emacs/compare/
> allow-setting-driver-options
>
> I think this behavior could be made conditional on the presence of
> the
> correct libgccjit ABI version, by declaring the variable in C code,
> and then everyone on a newer gcc would be able to reap the benefits,
> and everyone else could still use the branch, but only with the
> standard linker flags as before (or passing LIBRARY_PATH if that's
> supported on their platform).
>
>> Another option would be to set our self the LIBRARY_PATH before
> invoking
>> the compiler only in the async process.  Have you already tried
> using
>> `comp-async-env-modifier-form' for this?
>
>
> LIBRARY_PATH does work on GNU binutils: the concern for my nixpkgs
> branch is for usage on Darwin, where that environment variable
> doesn't
> do anything. To get anywhere there, we have to have a way to pass
> command-line arguments... /-:
>
> Besides that though, I think it might be useful for folks who want to
> specify that other linkers should be used (like gold or lld), or
> passing a -specs argument... I don't know if that's supported at all
> yet, but adding this option would be an easy way of finding out how
> unsupported it is (-;

Hi Andreas,

didn't know LIBRARY_PATH works only with binutils.  Agree this sounds
useful.

Regarfing the gcc version: ne option would be to just ifdef the body of
add_driver_options using
LIBGCCJIT_HAVE_gcc_jit_context_add_command_line_option and making clear
that the customize is effective only with GCC>=9.

But I think would be better to raise an error if
comp-native-driver-options is not empty and
gcc_jit_context_add_command_line_option is not available.

I think we should make this clear in the customize doc.

Do you already have copyright paperwork done?

Thanks!

  Andrea

PS I may have missed parts of your patch cause I think is untabifying
all touched files generating a very big diff.

-- 
akrl@sdf.org

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

[Andreas Fuchs]

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

On Sat, Aug 8, 2020 at 3:31 PM Andrea Corallo <akrl@sdf.org> wrote:
> Regarfing the gcc version: ne option would be to just ifdef the body of
> add_driver_options using
> LIBGCCJIT_HAVE_gcc_jit_context_add_command_line_option and making clear
> that the customize is effective only with GCC>=9.
>
> But I think would be better to raise an error if
> comp-native-driver-options is not empty and
> gcc_jit_context_add_command_line_option is not available.
>
> I think we should make this clear in the customize doc.

Agreed - that makes sense. I've adjusted the patch accordingly, and
de-untabified the files that I touched (sorry about the whitespace churn,
leftover customization from another C codebase):

https://github.com/emacs-mirror/emacs/compare/feature/native-comp...antifuchs:allow-setting-driver-options

> Do you already have copyright paperwork done?

I signed copyright assignment papers for gnus back in 2001, but those
are only valid for those changes to gnus. I've requested assignment
paperwork for GNU Emacs changes now.

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

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

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

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Andreas Fuchs <asf@boinkor.net> writes:

> On Sat, Aug 8, 2020 at 3:31 PM Andrea Corallo <akrl@sdf.org> wrote:
>> Regarfing the gcc version: ne option would be to just ifdef the
> body of
>> add_driver_options using
>> LIBGCCJIT_HAVE_gcc_jit_context_add_command_line_option and making
> clear
>> that the customize is effective only with GCC>=9.
>>
>> But I think would be better to raise an error if
>> comp-native-driver-options is not empty and
>> gcc_jit_context_add_command_line_option is not available.
>>
>> I think we should make this clear in the customize doc.
>
> Agreed - that makes sense. I've adjusted the patch accordingly, and
> de-untabified the files that I touched (sorry about the whitespace
> churn,
> leftover customization from another C codebase):
>
> https://github.com/emacs-mirror/emacs/compare/feature/
> native-comp...antifuchs:allow-setting-driver-options

From the patch:

> + #ifdef LIBGCCJIT_HAVE_gcc_jit_context_add_command_line_option
> + DEF_DLL_FN (void, gcc_jit_context_add_driver_option,
> +             (gcc_jit_context *ctxt, const char *optname));
> + #endif

[...]

> + #ifdef LIBGCCJIT_HAVE_gcc_jit_context_add_command_line_option
> +   LOAD_DLL_FN (library, gcc_jit_context_add_driver_option);
> + #endif

The above should not be ifdef'd as they allow the function to be used
only if present in the library in use at runtime on Windows systems.

Unfortunatelly we do not have such system for Linux where the decision
to include the call is done at compile time.  So unless we implement
that too also the call site has to be a little changed to handle this.

Please have a look for that into in Fcomp_libgccjit_version where we use
gcc_jit_version_*.  These are the only "optional" libgccjit entry point
we used so far.

>> Do you already have copyright paperwork done?
>
> I signed copyright assignment papers for gnus back in 2001, but those
> are only valid for those changes to gnus. I've requested assignment
> paperwork for GNU Emacs changes now.

Super!

Thanks

  Andrea

-- 
akrl@sdf.org

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

[Andreas Fuchs]

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

On Sun, Aug 9, 2020 at 3:58 AM Andrea Corallo <akrl@sdf.org> wrote:
> From the patch:
> > + #ifdef LIBGCCJIT_HAVE_gcc_jit_context_add_command_line_option
> > + DEF_DLL_FN (void, gcc_jit_context_add_driver_option,
> > +             (gcc_jit_context *ctxt, const char *optname));
> > + #endif
> [...]
> > + #ifdef LIBGCCJIT_HAVE_gcc_jit_context_add_command_line_option
> > +   LOAD_DLL_FN (library, gcc_jit_context_add_driver_option);
> > + #endif
>
> The above should not be ifdef'd as they allow the function to be used
> only if present in the library in use at runtime on Windows systems.
>
> Unfortunatelly we do not have such system for Linux where the decision
> to include the call is done at compile time.  So unless we implement
> that too also the call site has to be a little changed to handle this.
>
> Please have a look for that into in Fcomp_libgccjit_version where we use
> gcc_jit_version_*.  These are the only "optional" libgccjit entry point
> we used so far.

Ah, I misread the #ifdef condition above those. Makes sense, I've adjusted
the branch and added one more commit that should ensure we pass the
`comp-native-driver-options' to async compilation child processes
correctly.

This patch builds on my system, builds on darwin under nix (with some
additional changes to emit "-L" library path entries), and asynchronously
compiles code, too!

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

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

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

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Andreas Fuchs <asf@boinkor.net> writes:

> On Sun, Aug 9, 2020 at 3:58 AM Andrea Corallo <akrl@sdf.org> wrote:
>> From the patch:
>> > + #ifdef LIBGCCJIT_HAVE_gcc_jit_context_add_command_line_option
>> > + DEF_DLL_FN (void, gcc_jit_context_add_driver_option,
>> > +             (gcc_jit_context *ctxt, const char *optname));
>> > + #endif
>> [...]
>> > + #ifdef LIBGCCJIT_HAVE_gcc_jit_context_add_command_line_option
>> > +   LOAD_DLL_FN (library, gcc_jit_context_add_driver_option);
>> > + #endif
>>
>> The above should not be ifdef'd as they allow the function to be
> used
>> only if present in the library in use at runtime on Windows
> systems.
>>
>> Unfortunatelly we do not have such system for Linux where the
> decision
>> to include the call is done at compile time.  So unless we
> implement
>> that too also the call site has to be a little changed to handle
> this.
>>
>> Please have a look for that into in Fcomp_libgccjit_version where
> we use
>> gcc_jit_version_*.  These are the only "optional" libgccjit entry
> point
>> we used so far.
>
> Ah, I misread the #ifdef condition above those. Makes sense, I've
> adjusted
> the branch and added one more commit that should ensure we pass the
> `comp-native-driver-options' to async compilation child processes
> correctly.
>
> This patch builds on my system, builds on darwin under nix (with
> some 
> additional changes to emit "-L" library path entries), and
> asynchronously 
> compiles code, too!

Sounds great.

Some small notes:

> + static void
> + add_driver_options ()
> + {
> +   Lisp_Object options = Fsymbol_value (Qcomp_native_driver_options);
> + 
> + #ifdef LIBGCCJIT_HAVE_gcc_jit_context_add_command_line_option

I think here would be better to use something like

#if defined (LIBGCCJIT_HAVE_gcc_jit_context_add_driver_option) || defined (WINDOWSNT)

plus the pragma to cleanup the warning as we do in Fcomp_libgccjit_version.

> +   while (CONSP (options))
> +     {
> +       gcc_jit_context_add_driver_option (comp.ctxt, SSDATA (XCAR (options)));
> +       options = XCDR (options);
> +     }
> + #else
> +   if (CONSP (options))
> +     {
> +       xsignal1 (Qnative_compiler_error,
> +                 build_string ("Customizing native compiler options via `comp-native-driver-options' is only available on libgccjit version 9 and above."));

We should break this line to be max 80 columns wide.

> +     }
> + #endif
> + }

[...]

With those changes looks good to me once the paperwork is completed.

Thanks!

  Andrea
  
-- 
akrl@sdf.org

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

[Andreas Fuchs]

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

Thanks for the notes - I've pushed an updated version that includes the
(hopefully) corrected #if / #pragma usage to remain compatible on windows,
broke the long line & resolved the merge conflict against the latest HEAD
of feature/native-comp.

I also just got word from the FSF that my copyright assignment for GNU
Emacs is completed (and received the countersigned assignment papers as
PDF) - if the patch looks good to you, I think legally you're ok to merge
(-:

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

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

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

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Andreas Fuchs <asf@boinkor.net> writes:

> Thanks for the notes - I've pushed an updated version that includes
> the (hopefully) corrected #if / #pragma usage to remain compatible on
> windows, broke the long line & resolved the merge conflict against
> the latest HEAD of feature/native-comp.
>
> I also just got word from the FSF that my copyright assignment for
> GNU Emacs is completed (and received the countersigned assignment
> papers as PDF) - if the patch looks good to you, I think legally
> you're ok to merge (-:

Hi Andreas,

Super thanks!

I've rebased your branched, did some minor changes (broke two long lines
and squashed two commits).

I pushed it in scratch/native-comp-gcc-driver-options as I was thinking:

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'.

Any thoughts?

  Andrea

-- 
akrl@sdf.org

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

[Andreas Fuchs]

[-- 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 --]

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

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Andreas Fuchs <asf@boinkor.net> writes:

> 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.

Mmhh I guess a third way would be to expose a function the return a list
of all the available and effective features (ATM we have also
`comp-libgccjit-version').

Dunno, unless somebody has some formed opinion I'm fine also with
exposing for now `comp-native-driver-options-available-p'.

  Andrea

-- 
akrl@sdf.org

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

[Andreas Fuchs]

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

On Thu, Aug 20, 2020 at 12:43 PM Andrea Corallo <akrl@sdf.org> wrote:

> Mmhh I guess a third way would be to expose a function the return a list
> of all the available and effective features (ATM we have also
> `comp-libgccjit-version').
>
> Dunno, unless somebody has some formed opinion I'm fine also with
> exposing for now `comp-native-driver-options-available-p'.


I went ahead and pushed the change where I
implement `comp-native-driver-options-available-p' to my fork's
scratch/native-comp-gcc-driver-options branch at
https://github.com/antifuchs/emacs/tree/scratch/native-comp-gcc-driver-options.
Hope that works!

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

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

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

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Andreas Fuchs <asf@boinkor.net> writes:

> On Thu, Aug 20, 2020 at 12:43 PM Andrea Corallo <akrl@sdf.org> wrote:
>
>     Mmhh I guess a third way would be to expose a function the return
>     a list
>     of all the available and effective features (ATM we have also
>     `comp-libgccjit-version').
>    
>     Dunno, unless somebody has some formed opinion I'm fine also with
>     exposing for now `comp-native-driver-options-available-p'.
>
>
> I went ahead and pushed the change where I implement 
> `comp-native-driver-options-available-p' to my fork's scratch/
> native-comp-gcc-driver-options branch at https://github.com/antifuchs
> /emacs/tree/scratch/native-comp-gcc-driver-options. Hope that works!

Hi Andreas,

I pulled your branch, changed few stuffs on top and pushed to
scratch/native-comp-gcc-driver-options.

Please have a look to see you are satisfied and works for you so we can
merge it.

Thanks

  Andrea

-- 
akrl@sdf.org

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

[Andreas Fuchs]

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

On Mon, Aug 24, 2020 at 4:49 AM Andrea Corallo <akrl@sdf.org> wrote:

> Hi Andreas,
>
> I pulled your branch, changed few stuffs on top and pushed to
> scratch/native-comp-gcc-driver-options.
>
> Please have a look to see you are satisfied and works for you so we can
> merge it.
>

I tested it out & it does work when compiled outside of nix - I see a weird
failure about internal functions not being defined when I install it as
part of nix, but I've convinced myself that this is related to the eln
cache directory change that went in since I started this work & that still
requires handling on the nix side, nothing to do with my patch on the emacs
side (:

I think you can merge this! Thanks so much!
-- 
Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs

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

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

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Andreas Fuchs <asf@boinkor.net> writes:

> I tested it out & it does work when compiled outside of nix - I see a
> weird failure about internal functions not being defined when I
> install it as part of nix, but I've convinced myself that this is
> related to the eln cache directory change that went in since I
> started this work & that still requires handling on the nix side,
> nothing to do with my patch on the emacs side (:
>
> I think you can merge this! Thanks so much! 

Merged as aa526c9470, thank you!

We can always improve it later on if we feel.

Ciao

   Andrea

PS closing this

-- 
akrl@sdf.org