[bug#36043] Add Geany

> I actually packaged scintilla

Nice!

> but I failed unbundling it from Geany.  I attach the three patches I
> put up so far.

The scintilla package is not producing a shared library
(libscintilla.so). That is why you were not able to link it to geany. It
took a bit of substitute* surgery of the makefiles, but I managed to get
this working. Please see my attached patches. Ideally, we should get
scintilla and geany upstreams to support unbundling. Could you raise
these issues upstream?

> Subject: [PATCH 1/3] gnu: Add scintilla license.
>
> * guix/licenses.scm (scintilla): New variable.

The scintilla license is the ISC license. See
https://directory.fsf.org/wiki/License:ISC

> +         (replace 'build
> +           (lambda _ (invoke "make" "GTK3=1" "CC=gcc" "-Cgtk")))

This can be done by specifying #:make-flags. No need to replace the
build phase.

> +         (replace 'install
> +           (lambda* (#:key outputs #:allow-other-keys)
> +             (let* ((out (assoc-ref outputs "out"))
> +                    (lib (string-append out "/lib/scintilla"))
> +                    (include (string-append out "/include/scintilla")))
> +               (install-file "bin/scintilla.a" lib)
> +               (for-each (lambda (f) (install-file f include))
> +                         (find-files "include/" "."))
> +               #t))))))

The headers should be installed in /include, not in
/include/scintilla. The libraries should be installed in /lib, not in
/lib/scintilla.

The changes specified in the comments above are also included in the
attached patches. Please feel free to refine my patches as required.

Thanks!

Hello,

Arun Isaac <arunisaac@systemreboot.net> writes:

>> I actually packaged scintilla
> The scintilla package is not producing a shared library
> (libscintilla.so). That is why you were not able to link it to geany. It
> took a bit of substitute* surgery of the makefiles, but I managed to get
> this working. Please see my attached patches.

Thank you for keeping the ball rolling!

> Ideally, we should get scintilla and geany upstreams to support
> unbundling. Could you raise these issues upstream?

I have bad news: see 

    https://sourceforge.net/p/scintilla/feature-requests/555/

It may not be worth to unbundle Scintilla, then.

Guix has no proper way to use inputs' static libraries in a package?

> The scintilla license is the ISC license. See
> https://directory.fsf.org/wiki/License:ISC

This doesn't look right. See https://www.scintilla.org/License.txt
This is not ISC.

> The headers should be installed in /include, not in
> /include/scintilla. The libraries should be installed in /lib, not in
> /lib/scintilla.

Hmm I think I made the same mistake in nauty… because I saw another
packages doing it too. So there are at least 2 other packages in the
code base doing the same.

> The changes specified in the comments above are also included in the
> attached patches. Please feel free to refine my patches as required.

Since then, Scintilla team released 4.1.7.

WDYT?

Regards,

> I have bad news: see 
>
>     https://sourceforge.net/p/scintilla/feature-requests/555/
>
> It may not be worth to unbundle Scintilla, then.

This isn't particularly bad news. In that thread, Scintilla has agreed
to allow an optional shared library build for people (like us) who
really want it. But, the issue has been closed because it has been many
years and no one has volunteered a patch.

I think we should go ahead with our unbundled shared library Scintilla
package. We could also contribute our work upstream to Scintilla and
they seem willing to accept it.

> Guix has no proper way to use inputs' static libraries in a package?

We could make the static library scintilla package a native-input of
geany and add a phase copying the static library to the appropriate path
before building. Normally, static libraries embedded by upstream in the
source make it harder to update. If Guix controls the embedding, this
problem would admittedly cease to exist. But, I think we should still
prefer the shared library approach because shared libraries are more
efficient on disk and memory usage.

>> The scintilla license is the ISC license. See
>> https://directory.fsf.org/wiki/License:ISC
>
> This doesn't look right. See https://www.scintilla.org/License.txt
> This is not ISC.

The wording of both these licenses are so similar that I would consider
them to be effectively the same. But, I am not a lawyer, and I can't
claim to know too much about copyright. Should we raise this question
with guix-devel?

>> The headers should be installed in /include, not in
>> /include/scintilla. The libraries should be installed in /lib, not in
>> /lib/scintilla.
>
> Hmm I think I made the same mistake in nauty… because I saw another
> packages doing it too. So there are at least 2 other packages in the
> code base doing the same.

Note that some packages like gsl put the headers in /include/gsl because
they are meant to be included, say as

#include <gsl/gsl_vector.h>

and not as

#include <gsl_vector.h>

So, the include headers install location is dependent on the package's
conventions.

As for nauty, their documentation specifies including as

#include <nauty.h>

So, the headers should be installed to /include.

> Since then, Scintilla team released 4.1.7.

Ok. Let's update our Scintilla package to 4.1.7. Shouldn't be a problem.

Hello,

Arun Isaac <arunisaac@systemreboot.net> writes:

> This isn't particularly bad news. In that thread, Scintilla has agreed
> to allow an optional shared library build for people (like us) who
> really want it. But, the issue has been closed because it has been many
> years and no one has volunteered a patch.

Scintilla has agreed to allow an optional shared library if there is
also zero maintenance on their side (even when their ABI breaks). Since
this would eventually require maintenance, the submitter dropped
their request.

> I think we should go ahead with our unbundled shared library Scintilla
> package. We could also contribute our work upstream to Scintilla and
> they seem willing to accept it.

OTOH, using the static library is possibly (I failed at that, too)
straightforward, in the sense that we would not patch Scintilla. It is
worth considering this, too.

In any case, I do not volunteer to contribute our work upstream as it is
still above my pay grade.

> The wording of both these licenses are so similar that I would consider
> them to be effectively the same. But, I am not a lawyer, and I can't
> claim to know too much about copyright. Should we raise this question
> with guix-devel?

Scintilla's license has one more clause, but we can ask Guix devel.

> Note that some packages like gsl put the headers in /include/gsl because
> they are meant to be included, say as
>
> #include <gsl/gsl_vector.h>
>
> and not as
>
> #include <gsl_vector.h>
>
> So, the include headers install location is dependent on the package's
> conventions.
>
> As for nauty, their documentation specifies including as
>
> #include <nauty.h>
>
> So, the headers should be installed to /include.

OK. And what about the lib/, i.e., when should it be "/lib/name" instead
of "/lib/"

> Ok. Let's update our Scintilla package to 4.1.7. Shouldn't be a problem.

Indeed. Let's first sort out the issues around license (I'm going to
ask Guix devel about it) and bundling first.

Regards,

>> I think we should go ahead with our unbundled shared library Scintilla
>> package. We could also contribute our work upstream to Scintilla and
>> they seem willing to accept it.
>
> OTOH, using the static library is possibly (I failed at that, too)
> straightforward, in the sense that we would not patch Scintilla. It is
> worth considering this, too.

I would prefer the shared library because it is more efficient on
memory/disk usage and it seems cleaner and more modular. However,
scintilla is a small library and is not used by too many packages,
therefore the advantages are small. Meanwhile, patching scintilla to
build a shared library is messy and using the static library would
indeed be easier. But, if we are using the static library, why should we
unbundle at all?

I don't know if Guix has a clear policy on these matters. I think we
should consult guix-devel and ask for others' opinions.

> In any case, I do not volunteer to contribute our work upstream as it is
> still above my pay grade.

No problem, I understand.

> Scintilla's license has one more clause, but we can ask Guix devel.

I guess we should use the hpnd license now, as discussed in guix-devel.

> And what about the lib/, i.e., when should it be "/lib/name" instead
> of "/lib/"

I don't have as good an answer for this. A quick look at my
~/.guix-profile/lib shows almost all packages having their shared
libraries in /lib, not in /lib/name. And, just including scintilla in
geany's inputs and passing '-lscintilla' in geany_LDFLAGS was enough for
the linker to find libscintilla.so correctly. So, I assumed I had done
it right. :-P

Hi,

Just a friendly ping. Can we finish this package one way or the other --
with or without a bundled scintilla? Perhaps you can just leave a TODO
comment for someone to pick up on later. I'm just worried it's taking
too long for this relatively simple package.

Thanks,
Arun.