The editors/micro port is still on 1.4.1, while 2.0.4 is released. I tried to make the necessary Makefile changes myself but gave up; I'm a novice at porting and there are some difficulties involved with this change. This Github issue provides some background: https://github.com/zyedidia/micro/issues/1711 The project uses gmake internally, and its Makefile requires being in the Git repository to determine version information. Currently, the port seems to work by ignoring the project's Makefile and doing the build itself, inserting the -ldflags, but I don't believe this is the right approach. It would require duplicating code between the two Makefiles (and also the port Makefile currently hardcodes the build date as August 9 2018, which is silly - the project's Makefile runs a Go script that determines the actual date). I couldn't make a patch myself because I couldn't figure out how to make it clone the repository instead of just downloading an archive.
Created attachment 215386 [details] patch
That patch still ignores the project's makefile and hardcodes a build date. I'm sure build date is less important than version, but is there no way to let the project's own stuff handle this?
(In reply to rlwestlund from comment #2) Why?
I think I explained my thinking in the first comment and the linked issue. It seems to me like duplicating code between the port and the project is something we should avoid if we can. Especially since the hardcoded build date will be wrong; is that not worse than just leaving it blank?
(In reply to rlwestlund from comment #4) > Especially since the hardcoded build date will be wrong; is that not worse than just leaving it blank? Compiling in the actual build date instead of a fixed date is a source of non-reproducibility [1] that is best avoided if possible. [1] https://reproducible-builds.org/docs/timestamps/
(In reply to rlwestlund from comment #4) I don't understand why you are so focused on the build date, what is a correct build date for you? The hardcoded build date is the date of the release, is it better than the date of the build (which will change quite often on FreeBSD)? We'll have to patch the project Makefile if we want to use it...: ===> Building micro from . can't load package: package .: no Go files in /usr/ports/editors/micro/work/micro-2.0.4 *** Error code 1
I didn't consider that true build dates are a source of unreproduceability. That's a good point. > I don't understand why you are so focused on the build date, what is a correct build date for you? The hardcoded build date is the date of the release, is it better than the date of the build (which will change quite often on FreeBSD)? My thinking was that the build date should be the date on which it was built. Including the date of release and calling it build date is just misleading. However, I've been more or less that the build date is not something that belongs compiled in, and doing it this way does allow the port to build without gmake and git as build dependencies. Though it is possible to compile it this way and include the proper version and commit hash without including build date. It prints as "Unknown" with `micro -version`. Unless it's a custom I'm not aware of that "build date" actually means release date, (which doesn't seem so because the project's makefile includes the actual build date,) wouldn't that be preferable to having `micro -version` output "Compiled on..." a date it wasn't compiled on?
Build info is available at https://gitlab.com/swills/freebsd-ports/pipelines/159423158
Well, in the time this has taken, Micro version 2.0.6 has been tagged.
A commit references this bug: Author: swills Date: Thu Jun 25 03:23:07 UTC 2020 New revision: 540361 URL: https://svnweb.freebsd.org/changeset/ports/540361 Log: editors/micro: update to 2.0.4 PR: 247099 Submitted by: rlwestlund@gmail.com Changes: head/editors/micro/Makefile head/editors/micro/distinfo
Sorry it took so long, went ahead and committed it as-is. I'll try to do the update to 2.0.5 more quickly if someone sends a patch. Thanks!