lcalc, include/Lfunction vs include/libLfunction

18 views
Skip to first unread message

Samuel Lelievre

unread,
Sep 2, 2019, 9:02:00 AM9/2/19
to sage-packaging
Hi all

For information, a discussion about lcalc, specifically
include/Lfunction vs include/libLfunction, is taking place
on Trac and on sage-devel.

- Sage Trac ticket 28224: spkg-configure.m4 for lcalc

- sage-devel, 2019-09-02, Dima Pasechnik
  SAGE_LOCAL/include/libLfunction vs include/Lfunction

Kind regards
Samuel

Andreas Enge

unread,
Sep 2, 2019, 9:29:59 AM9/2/19
to sage-pa...@googlegroups.com
Thanks, Samuel!

On Mon, Sep 02, 2019 at 06:02:00AM -0700, Samuel Lelievre wrote:
> For information, a discussion about lcalc, specifically
> include/Lfunction vs include/libLfunction, is taking place
> on Trac and on sage-devel.

What I do not quite get - since the package is called "lcalc", why does it
not use "include/lcalc"? To add a third option to the discussion, but which
sounds the most reasonable to me.

In Guix, as usual we did not change anything and kept libLfunction.

Andreas

Dima Pasechnik

unread,
Sep 2, 2019, 9:41:09 AM9/2/19
to sage-packaging
libLfunction is a change done by Sage, upstream had Lfunction.

Also, the dylib is called libLfunction.

lcalc is a binary, statically linked with libLfunction.
So include/lcalc seems to be a wrong choice to me.

>
> Andreas
>
> --
> You received this message because you are subscribed to the Google Groups "sage-packaging" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-packagin...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-packaging/20190902132954.GA12179%40jurong.

Andreas Enge

unread,
Sep 2, 2019, 10:00:06 AM9/2/19
to sage-pa...@googlegroups.com
On Mon, Sep 02, 2019 at 04:40:56PM +0300, Dima Pasechnik wrote:
> libLfunction is a change done by Sage, upstream had Lfunction.
> Also, the dylib is called libLfunction.

Okay, then Lfunction sounds like the right thing. At the same time, I find
it a bit too generic (a reproach to make to upstream, then).

Actually we used Sage as upstream, since the real upstream seems to have
disappeared. Looking again at my code, it has almost more comments
complaining about the messy state of affairs than actual functional
lines...

There is also this:
;; Add --std=c++11 to be compatible with the "auto" keyword
;; introduced by lcalc-using-namespace-std.patch.
(("^#EXTRA= -pg")
"EXTRA=--std=c++11")))
Are these kinds of changes really necessary?

And so far our package does not use pari-gp as an input, I just wanted
to get closer to a compiling Sage. So I am unsure how functional our lcalc
actually is...

Andreas

Dima Pasechnik

unread,
Sep 2, 2019, 10:40:27 AM9/2/19
to sage-packaging
it  would be great if you swithched to Lfunction/, then it could be made uniform across distros.

--
You received this message because you are subscribed to the Google Groups "sage-packaging" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-packagin...@googlegroups.com.

Isuru Fernando

unread,
Sep 2, 2019, 11:30:40 AM9/2/19
to sage-pa...@googlegroups.com
I fixed Makefile.patch in conda-forge to use include/Lfunction, but kept a symlink for include/libLfunction for now.

Isuru

Andreas Enge

unread,
Sep 2, 2019, 2:17:09 PM9/2/19
to sage-pa...@googlegroups.com
On Mon, Sep 02, 2019 at 05:40:10PM +0300, Dima Pasechnik wrote:
> it  would be great if you swithched to Lfunction/, then it could be made
> uniform across distros.

No problem, three lines of code to delete :-)

Andreas

Reply all
Reply to author
Forward
0 new messages