lcalc, include/Lfunction vs include/libLfunction

[Samuel Lelievre]

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

  https://trac.sagemath.org/ticket/28224

- sage-devel, 2019-09-02, Dima Pasechnik

  SAGE_LOCAL/include/libLfunction vs include/Lfunction

  https://groups.google.com/d/topic/sage-devel/fAPWh1G8_Qw/discussion

Kind regards

Samuel

[Andreas Enge]

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]

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]

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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-packaging/20190902140002.GA12982%40jurong.

[Isuru Fernando]

I fixed Makefile.patch in conda-forge to use include/Lfunction, but kept a symlink for include/libLfunction for now.

Isuru

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-packaging/CAAWYfq3tb16YFU%3D01WhUSd3tUr62GGMhvpsEY5fim-afO1MmPg%40mail.gmail.com.

[Andreas Enge]

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