Opened 19 months ago

Closed 18 months ago

Last modified 18 months ago

#28785 closed enhancement (duplicate)

Make spkg-configure.m4 more verbose

Reported by: saraedum Owned by:
Priority: trivial Milestone: sage-duplicate/invalid/wontfix
Component: build: configure Keywords: spkg-configure.m4
Cc: embray Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: u/saraedum/verbose-configure (Commits, GitHub, GitLab) Commit: 4379ec9f4c646c2b430766b5eec0ebdb2f2534a2
Dependencies: Stopgaps:

Status badges

Description (last modified by saraedum)

Some spkg-configure.m4 implement a message at the end that says something like will use the package X from the system. It's confusing to me at least that not all packages report this immediately. (They do in the final listing of packages.)

More importantly, it would be nice if all packages that do implement such a check would be explicit about not having passed that test. For example, in the final listing of packages, it would be nice if we had something similar to:

alib will not be installed (using system package)
blib will be installed (no suitable system package)
clib # no additional comment, does not have a spkg-configure.m4 yet.

Change History (8)

comment:1 Changed 19 months ago by saraedum

  • Description modified (diff)

comment:2 Changed 19 months ago by jhpalmieri

I find the summary toward the end of the main config.log to be somewhat helpful, where it says things like

bzip2-1.0.6-20150304.p0 will not be installed (configure check)

It would be more helpful if this were not buried inside the log file, and it would be even more helpful if it would say (as you are suggesting)

cliquer-1.21.p4 will be installed (no suitable system package)

but also something like

cmake-3.11.0 will not be installed (optional package)

I don't know the best wording to handle all of the various cases: system package found (and do you distinguish in this case among standard, optional, or experimental?), standard package but no system package found, optional, experimental.

comment:3 Changed 19 months ago by saraedum

  • Branch set to u/saraedum/verbose-configure

comment:4 Changed 19 months ago by saraedum

  • Commit set to 4379ec9f4c646c2b430766b5eec0ebdb2f2534a2

Trying to debug a problem, I got really confused by some of the things in the sage_spkg_configure.m4. So I added some comments that I would have found helpful (and fixed the comment on the top explaining CHECK.)

I also restructured the logic a bit. Now it seems more natural to me and this probably also fixed a bug. This might have introduced a few new problems, I haven't really checked carefully, but it works for me.

I changed the meaning of force when there is no check. It now actually tells Sage not to install that package.

[should have done this on GitLab so I can comment inside my changeset…]


New commits:

4379ec9Make spkg-configure.m4 more verbose

comment:5 follow-up: Changed 19 months ago by saraedum

This is now https://gitlab.com/sagemath/sage/merge_requests/38 and https://trac.sagemath.org/ticket/28788

[sorry, but there is no good way to migrate an existing trac ticket to a GitLab Merge Request.]

Last edited 19 months ago by saraedum (previous) (diff)

comment:6 Changed 19 months ago by saraedum

  • Milestone changed from sage-9.0 to sage-duplicate/invalid/wontfix
  • Status changed from new to needs_review

comment:7 Changed 18 months ago by embray

  • Resolution set to duplicate
  • Status changed from needs_review to closed

comment:8 in reply to: ↑ 5 Changed 18 months ago by embray

Replying to saraedum:

[sorry, but there is no good way to migrate an existing trac ticket to a GitLab Merge Request.]

That might be a nice feature to add. E.g. "resolves #XXXXX" or "fixes #XXXXX" in the merge request title or body could do this...

Note: See TracTickets for help on using tickets.