Thank you, Dr. Wheeler, for sharing all this context with us. For whatever it is worth, I am personally, quite happy with the URL that Norm made public for us. It makes packaging *possible* which is huge.
FL's suggestions seem reasonable to me if the goal is to minimize friction for package maintainers; however, if this poses problems/inconvenience upstream as you suggest, then how about compromise with a README in the metamath-program.zip for now? At a bare minimim, it might be nice to explain the (mildly non-standard) compilation procedure, as well as link to the set.mm repo. I am currently holding off on submitting a packing to Void Linux until it becomes clear what exactly source bundle we want Metamath to provide. As a side note, what are thoughts on the idea of also providing a shell script wrapper "codifies" things like downloading, updating, listing etc the *.mm databases? This might make packaging more of a simple turn-key solution, so that metamath installs files to more standard filesystem locations. I certainly would not mind writing such a script, which would likely turn out a lot like the one I shared in a previous post here. Cheers, "David A. Wheeler" <[email protected]> wrote: > David A. Wheeler: > > > I think we can revisit and improve things, but whatever build and > > > distribution process changes are made needs to be something that Norm is > > > willing to accept. Norm has limited time and his own preferences. > > On Fri, 20 Dec 2019 04:52:22 -0800 (PST), "'fl' via Metamath": > > Why does he let people waste their time talking if he knows he doesn't want > > it ? > > It's not a waste of time. > > Norm is happy to let *other* people use the autotools. After all, > using the autotools typically produces a Metamath executable with > significantly > higher performance for certain operations. > > However, Norm prefers using his own tools & doesn't use the autotools > *himself*, > at least not at this time. > > So the compromise has been for Norm to use whatever tools he wants, and Norm > simply includes various autotools files like configure.ac in the Metamath > release. > That makes it *possible* for recipients to use the autotools. > Since Norm doesn't run the autotools himself, recipients can't be guaranteed > that the > "configure" file is up-to-date. Instead, recipients who want to use the > autotools > have to run "autoreconf" themselves to *generate* the configure file, and > then use > the configure file as usual to do the rest of the build. > > Yes, this is more steps than usual. However, > this is not completely unknown. You also have to do this extra step with some > GNU packages if you download a development version instead of an actual > release. > It is unusual for *released* software. Typically *releases* of software that > support the autotools include a pre-generated configure file that was created > by > the autotools as part of the process for creating a release. > But doing that would require Norm to install & run the autotools. > Norm might be willing to do that now, but he didn't want to do that in > the past & that change is up to him. > > I'd be happy to modify the autotools files (e.g., configure.ac) to change > things. > I just got back from a trip to Florida, & Christmas is coming, but once > things get > a little quieter I'd be happy to help. I would just need to know what changes > need to be made. > > --- David A. Wheeler > > -- > You received this message because you are subscribed to the Google Groups > "Metamath" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/metamath/E1iiRY9-0007E6-Vq%40rmmprod07.runbox. -- You received this message because you are subscribed to the Google Groups "Metamath" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/metamath/5dff0027.A1B02eSlNqNRQbtF%25heiphohmia%40wilsonb.com.
sig.asc
Description: application/pgp-encrypted
