search

lcn2 / calc

C-style arbitrary precision calculator
http://www.isthe.com/chongo/tech/comp/calc/index.html
Other
358 stars 51 forks source link

Makefile.ship missing from the 2.14.0.12 release archive? #42

Closed mattdm closed 2 years ago

mattdm commented 2 years ago

It seems that this change https://github.com/lcn2/calc/commit/e5c8f00adc1b857391a3d12c181f46b767ae6170#r61722277 introduces a build dep on Makefile.ship, resulting in 

  make[1]: *** No rule to make target '../Makefile.ship', needed by 'Makefile.simple'.  Stop.

when trying to build as normal. I'm not using Makefile.simple, so possibly the fix is actually to just remove it from LATE_TARGETS in the main Makefile and TARGETS in custom/Makefile?

Possibly all of this complication suggests that it might be time to consider more modern alternatives to Make altogether.

mattdm commented 2 years ago

In case that wasn't clear — have a flag for when you want to actually generate this file?

Or maybe you just meant to include Makefile.ship. I dunno. :)

For now, I'm just going to do touch Makefile.ship before make to avoid the problem.

lcn2 commented 2 years ago

Hello @mattdm,

Thank you for your report.

The Makefile.ship should be in the release. Here is a link to it from the master branch should you need a current copy:

https://github.com/lcn2/calc/blob/master/Makefile.ship

From what package did you find Makefile.ship missing?

chongo (Landon Curt Noll) /\oo/\

pmetzger commented 2 years ago

I have the same problem. Building off of github as I always have:

make[1]: *** No rule to make target `../Makefile.ship', needed by `Makefile.simple'.  Stop.
pmetzger commented 2 years ago

(This is preventing me from upgrading MacPorts to 2.14.0.12.)

pmetzger commented 2 years ago

FYI:

$ ls  work/calc-2.14.0.12/Makefile*
work/calc-2.14.0.12/Makefile        work/calc-2.14.0.12/Makefile.simple
work/calc-2.14.0.12/Makefile.local
lcn2 commented 2 years ago

Hello @pmetzger and @mattdm,

Thank you for bringing this problem to our attention.

We plan to address this in an emergency 2.14.0.x release. See below for details.

Our general plan is to finally do away with the Makefile vs. Makefile.ship duality. Makefile.ship will be moved to Makefile. The Makefile at the top of the master branch will become the former contents of Makefile.ship. When the "calc*.src.rpm" and the source tarball file are released, there will be no Makefile.ship, but rather just Makefile (containing the former contents of Makefile.ship).

Makefile.local will include comments about how to better use it. Between releases, Makefile.local at the top of the master branch will contain how we typically build calc and test calc (FYI: we normally enable things such as -Werror -Wextra -pedantic). When we push out a release, Makefile.local will be stripped of non-comment lines. Thus, releases of calc, and, released "calc*.src.rpm" files and the source tarballs, will have a Makefile.local with only comments.

The "README.*" files and "HOWTO.INSTALL" file will be updated accordingly.

We plan to test on multiple platforms using the various package types. During this testing process we may skip versions and/or push out multiple pre-releases (i.e., releases that are not stable releases). Once our multi-platform testing shows success, and in particular the Makefile and Makefile.local and Makefile.simple exist and contain the proper contents, we will push out a "2.14.0.x+1" release as a stable release, for some value of x > 12. :-)

You are welcome, of course, to test and comment on the "2.14.0.x" non-stable releases if you wish. The publishing of "2.14.0.x+1" as a stable release will be your clue that this issue has been resolved. We will also follow up with a closing comment to this issue.

Thank you for your patience in this matter. Comments and suggestions welcome.

chongo (Landon Curt Noll) /\oo/\

mattdm commented 2 years ago

That sounds fine, although I still find the "stable / unstable" scheme confusing.

Would you consider moving to a semver scheme, where stable releases are like:

2.15.0 (next stable release) 2.15.1 (bugfix to stable release) 2.16.0 (stable release which adds backwards-compatible features 3.0.0 (stable release which has a compatibility break)

... and then the unstable releases leading up to any of those are tagged with -unstableX, like:

2.15.0-unstable1 (development leading up to 2.15.0)

?

lcn2 commented 2 years ago

Hello @mattdm.

We appreciate your suggestions and we have considered them in part.

tl;dr:

=-=

A few comments on calc versions:

Historically calc version x.y.something remains compatible for any other x.y.another version of calc. Calc version 2.14.x.y is compatible with other 2.14.a.b versions, for example.

Calc scripts that were written for 2.13.c.d versions might run into slight issues under version 2.14.x.y, for example, when a because of a builtin function that was added to 2.14.x.y. Such a new builtin function might complicate code written under a 2.13.c.d version, for example.

Any calc changes that might impact 2.14.x.y code will not be introduced until 2.15.0.0.

We use GitHub's 'pre-release' to indicate that a given release has not undergone extensive use and testing. A pre-release underwent a fair amount of testing, so a pre-release is NOT "alpha code unstable". A pre-release simply has not withstood the "test of time and place" that a release has undergone.

Typically, a 2.x.y.z pre-release that as solidified and been extensively used in both time and configurations will become a '2.x.y.z+1' GitHub release: I.e., declared stable.

It is, thankfully, a rare case when what we thought was a GitHub release (i.e., stable) has to have its 'stable' status withdrawn. Unfortunately, that is what happened with 2.14.0.12. The core code of calc 2.14.0.11 is good. Unfortunately, a mistake was made in our release process as a critical file was not released. Otherwise, 2.14.0.12 (if you can compile it) is fine.

We have a good idea that will simplify the release process AND make it less error prone to the kind of mistake that we made with 2.14.0.12. We will need to test the release process and push out, perhaps, a few pre-releases until we are satisfied that the 2.14.0.12 problem won't repeat itself. We are developing some internal tools to help of catch the kind of problem that we made with 2.14.0.12 so hopefully it won't happen again (in that same way).

So again, a GitHub release is a stable release that as stood the "test of time and place". Those who prefer "production class" releases only should use GitHub releases (i.e., stable).

A GitHub pre-release HAS undergone testing and is probably fine. Historically anything that is not a GitHub release (i.e., stable) was called "unstable", which is probably a poor choice of words. A GitHub pre-release is a tested release that simply might not be a "production class" release.

There is, in fact, alpha or potentially unstable code. That code is represented as the top of the main (master) branch. Cloning the GitHub repo and using commits that have NOT been tagged with a calc versions is NOT recommended unless you are curious and/or you want to alpha test calc code. We try to NOT break the top of the GitHub tree, but it can happen. Our alpha testing sites, sometimes run by different organizations git clone the calc repo and give is feedback on the top of the GitHub master branch.

Only tagged pre-releases and releases of the GitHub master branch represent code that has passed a fair amount of testing, and in the case of a GitHub release (not pre-release) has withstood a higher level of use "testify of time and place.

BTW: There are plans for calc version 3.x.y.z. This will involve some extensive internal changes that will impact those hardware implementations that depend on 2.a.b.c internals.

There are hardware implementations that use calc. They depend on calc's internal representation AND on calc's custom function services. Calc 2 commits to remaining hardware compatible over all calc 2.x.y.z releases.

There are plans for calc version 3. That version will establish a new hardware compatibility and internal representation. We anticipate a development fork where both new calc v2 and calc v3 will be developed concurrently. Even after the release of calc version 3, we plan to support calc version 2 for a LONG TIME.

mattdm commented 2 years ago

Thanks @lcn2. I guess the most useful thing to change from my perspective would be to stop incrementing z for "unstable" releases and instead use 2.x.y.z-pre1, 2.x.y.z-pre2, 2.x.y.z-pre3, etc. until you're ready to call it "stable", at which point the regular 2.x.y.z would apply. Even if the whole scheme isn't SemVer, package tooling these days is well-equipped to deal with that kind of -preN syntax.

lcn2 commented 2 years ago

Part of the program is that the old terms 'stable' and 'unstable' are misleading / incorrect terms. They were holdovers from a long ago process that should have been updated awhile ago. A better set of terms we plan to use going forward are:

Any untagged GitHub commits at the top of the master branch are alpha code / potentially less tested and may be unstable.

Unless your calc application is "production class" and/or "critical", @mattdm, the distinction between "production" and "tested" is not that important.

mattdm commented 2 years ago

From my point of view the main problem is that it's not apparent without external reference whether a release is intended to be "production" or "tested". I don't really care what the scheme is, but would like it to be indicated somehow in the release number / string. As you move to those new terms going forward, could you also consider including them directly somehow?

pmetzger commented 2 years ago

Another option: since you're now on Github and it's easy to ask people to test a checkout made against any tag or commit you like, you might simply drop having released versions you don't intend for people to package.

lcn2 commented 2 years ago

Just to be clear:

We do intend to mark with tags, GitHub releases that we intend for people to package. When we tag, we do so with the intend of encoring people such as yourself, @pmetzger, to package.

Untagged commits such as: https://github.com/lcn2/calc/commit/ad79b6384df1640ddfd7d81f2d66cc03ebbdd676 are alpha testing updates that are not yet worthy of packaging.

=-=

QUESTION on MacPorts:

When someone installs -lreadline -lhistory -lncurses, under what directory are both the include files and the link liberties installed?

We know that HomeBrew uses /opt/homebrew/opt/readline/lib for those 3 libs, and /opt/homebrew/opt/readline/include/readline for the .h files associated with each of those 3 libs.

We are just wondering where, someone using MacPorts and who as installed readline, history, and ncurses might find both the libraries and related header files.

QUESTION on MacPorts:

Does MacPorts have an environment variable similar to HomeBrew's $HOMEBREW_PREFIX (i.e., HOMEBREW_PREFIX=/opt/homebrew)?

lcn2 commented 2 years ago

You make good points @mattdm,

Just to be clear:

A "production" release is a "tested" release that has undergone extensive internal testing by other groups. For example, people who have built special purpose hardware that use calc has a computation framework and/or use calc custom function that connect to hardware. Those people run any new code through their internal qualification procedures via their own timeline / schedule. Until we get a 'green light' a "tested" form a quorum of such groups, a calc release remains tested and that is not declared "production".

Unless you have such a production qualification procedure, we recommend that you not concern yourself with the difference between "production" and "tested".

For most people, there is little need to wait for a "production" release. Unless you are one of those who has hardware that depends on calc, or makes use of special calc custom functions you compile in that relate to external devices (such as medical instruments), and "tested" release or any version number tagged commit is worth using.

Any tagged commit comes with a new version of calc that has been well tested. The resulting code base, and packaged assets (source tarball, source zip file, RPMs, source RPM, ...) are something we recommend that people use.

And unless you are interested in continuous integration and/or don't mind alpha code, you probably don't want to concern yourself with an untagged commit to the master branch.

We cannot simply rename a calc version to indicate, after the fact, that the release has passed a quorum qualification procedures from external groups. Calc version numbers are deeply imbedded in calc. The calc builtin function, version(), is used by people with special calc resource scripts to handle any calc version specific issues. Calc RPMs have the the calc version number embedded within them and changing the internal RPM metadata would change the cryptographic hash of the file: forcing those who have qualification procedures to re-qualify them.

How about this: What if we add "production" tags? A tag ion a different format, to GitHub that would sit alongside a v2.x.y.z tag for a "tested" calc version. A "prod-2.x.y.z" tag could be added to any release that received a "green light" from those with production qualification procedures.

mattdm commented 2 years ago

Yeah, that would definitely help. Thanks.

lcn2 commented 2 years ago

Thank you for your patience, @mattdm,

We are nearing the time to push out a calc v2.14.0.13 "tested" release. it contains some major changes to our release process. We need to focus on this testing now before modifying our release processes to add "prod-2.x.y.z" tags.

See the new issue we opened.

pmetzger commented 2 years ago

QUESTION on MacPorts:

BTW, complete documentation on MacPorts is available at: https://guide.macports.org/

When someone installs -lreadline -lhistory -lncurses, under what directory are both the include files and the link liberties installed?

That depends on your MacPorts configuration, but essentially everyone end up with stuff in /opt/local/{include,lib}

Generally, the MacPorts prefix is configurable, and a lot of effort is made to make sure that everything will build and run in any prefix. It is up to the Portfile to assure that "configure" (or whatever tools are used by the package) is informed of the prefix the individual user has selected. For example, the calc Portfile installs a Makefile.local with contains __PREFIX__ in strategic places, and then executes (in the post-patch phase):

post-patch {
    reinplace "s|___PREFIX___|${prefix}|" ${worksrcpath}/Makefile.local
}

which replaces __PREFIX__ with the appropriate MacPorts prefix.

It is not (in general) possible for an upstream package to know in advance what the prefix will be, and it generally isn't necessary, as the Portfile will tell the package.

We are just wondering where, someone using MacPorts and who as installed readline, history, and ncurses might find both the libraries and related header files.

So our Makefile.local patch contains:

--- Makefile.local.orig
+++ Makefile.local
@@ -1,1 +1,7 @@
 # Add below to override Makefile values (using :=) as in: HAVE_STRING_H:= YES
+PREFIX=___PREFIX___
+CALC_INCDIR:= ${PREFIX}/include/calc
+USE_READLINE:= -DUSE_READLINE
+READLINE_LIB:= -L${PREFIX}/lib -lreadline
+READLINE_EXTRAS:= -lhistory -lncurses
+ARCH_CFLAGS:=

As you can see, this is how we tell calc where to find things like the ncurses header files.

QUESTION on MacPorts:

Does MacPorts have an environment variable similar to HomeBrew's $HOMEBREW_PREFIX (i.e., HOMEBREW_PREFIX=/opt/homebrew)?

No such environment variable is visible to the user. A global variable is visible in Portfiles for the use of the Portfile author. Again, the Portfile is responsible for feeding enough information to the package's configuration system (for 80% of packages, that's autotools) to find any packages it depends on. The Portfile specifies any packages that a given package depends on so that they will be built before the package is built and will be accessible during the build.

lcn2 commented 2 years ago

Fixed in calc v2.14.0.13

Thank you @mattdm and @pmetzger for your feedback on this issue!

pmetzger commented 2 years ago

By the way, you can see the structure of the Portfile in

https://github.com/macports/macports-ports/blob/master/math/calc/Portfile