conditionalise installation of many spkg's?

[Dima Pasechnik]

We now have a good setup in place to make installation of an spkg conditional on presence of a compatible one

on the system---basically, just add a dozen or two lines to configure.ac.

Examples of packages already treated this way are curl, yasm, git. gcc.

Should there be an effort to do this for many more packages? (the 1st obvious candidate is patch).

Dima

[Erik Bray]

I have had an ongoing effort to use more system packages in a somewhat
"generic" way (see
https://groups.google.com/d/msg/sage-devel/nTwhCV89FXE/_7GdzGy4BgAJ)

Although that thread is 6 months old, I have been working more or less
on the same plan I outlined there, but the work has been stalled on
what I felt was necessary preliminary work which I could use some help
moving forward in terms of review... (see [1] [2] [3]).

That said, although I still consider proper package uninstallation an
important prerequisite to my bigger plans, that doesn't necessarily
prevent us from going ahead and making more spkgs conditional on
configure-time checks.

One thing I might do differently from your proposal: I have some
experimental code for an autoconf macro that can slurp in macros from
multiple sub-directories. The idea being that you could put little
.m4 files in each build/pkgs/<pkgname> dir with configure-time checks
for that specific package, rather than cluttering up configure.ac with
them. Perhaps I could try putting together a ticket for that...?

[1] https://trac.sagemath.org/ticket/22509
[2] https://trac.sagemath.org/ticket/24106
[3] https://trac.sagemath.org/ticket/22510

[Michael Orlitzky]

On 11/27/2017 07:39 AM, Erik Bray wrote:
>
> One thing I might do differently from your proposal: I have some
> experimental code for an autoconf macro that can slurp in macros from
> multiple sub-directories. The idea being that you could put little
> .m4 files in each build/pkgs/<pkgname> dir with configure-time checks
> for that specific package, rather than cluttering up configure.ac with
> them. Perhaps I could try putting together a ticket for that...?

PHP does this with its extensions, all of which are optional and have
their own configure flags. There's a shell script that essentially does

for f in build/pkgs/*/*.m4; do
echo "include(${f})"
done

and then that shell script is executed in the top-level configure.ac
with esyscmd:

esyscmd(./path/to/that/script)

The result is that the "include" commands get inserted into the
top-level configure.ac file before processing.

On the other hand, if we standardize on the name of the m4 file (i.e.
it's fixed but optional), then you could use "sinclude" to grab them all
at once, ignoring the errors from the ones that don't exist.

[Erik Bray]

On Mon, Nov 27, 2017 at 2:48 PM, Michael Orlitzky <mic...@orlitzky.com> wrote:
> On 11/27/2017 07:39 AM, Erik Bray wrote:
>>
>> One thing I might do differently from your proposal: I have some
>> experimental code for an autoconf macro that can slurp in macros from
>> multiple sub-directories. The idea being that you could put little
>> .m4 files in each build/pkgs/<pkgname> dir with configure-time checks
>> for that specific package, rather than cluttering up configure.ac with
>> them. Perhaps I could try putting together a ticket for that...?
>
> PHP does this with its extensions, all of which are optional and have
> their own configure flags. There's a shell script that essentially does
>
> for f in build/pkgs/*/*.m4; do
> echo "include(${f})"
> done
>
> and then that shell script is executed in the top-level configure.ac
> with esyscmd:
>
> esyscmd(./path/to/that/script)
>
> The result is that the "include" commands get inserted into the
> top-level configure.ac file before processing.

Neat--that's more or less how my thing works, except it just uses
esyscmd(find ...). Seems to work fine, but good to know there's prior
precedent for something like that. The core of my macro is

m4_foreach_w([f], m4_esyscmd_s([find build/pkgs -name
'spkg-configure.m4' -type f]), [m4_apply([m4_include], f)])

Each spkg-configure.m4 could, in turn, contain a macro with a standard
name like SAGE_CONFIGURE_<PKGNAME> which could also be expanded in
this loop, or elsewhere.

> On the other hand, if we standardize on the name of the m4 file (i.e.
> it's fixed but optional), then you could use "sinclude" to grab them all
> at once, ignoring the errors from the ones that don't exist.

I'm not really sure what you mean here. You still need to use some
kind of system command plus a loop, if you want to keep the m4 files
in build/pkgs/*/

[Michael Orlitzky]

On 11/27/2017 09:00 AM, Erik Bray wrote:
>
>> On the other hand, if we standardize on the name of the m4 file (i.e.
>> it's fixed but optional), then you could use "sinclude" to grab them all
>> at once, ignoring the errors from the ones that don't exist.
>
> I'm not really sure what you mean here.

Nothing ground-breaking, only that you might do something like...

for d in build/pkgs/*; do
echo "sinclude(${d}/spkg-configure.m4)"
done

without having to care whether or not spkg-configure.m4 exists in each
directory.

Now I'm curious why PHP does the loop in the shell script... how does
your "m4_foreach_w" loop behave if "find" outputs a path containing a space?

[Erik Bray]

In this case it won't unless there's a mistake in the source directory
tree (it should only return names like
"build/pkgs/<pkgname>/spkg-configure.m4", and package names can't
contain spaces.

If we wanted to make it more robust though that's easy enough.

[Dima Pasechnik]

yes, please! it would be much more flexible this way.