Solved How to clone the Git repository from Github

Yujiri

New Member


Messages: 10

I'm a novice porter trying to update the editors/micro port. I can get the port to build a modern version successfully, but version information is excluded from the binary despite the settings in the port's Makefile. I think the project is not designed for that information to be inserted by the port; it has its own Makefile that internally handles inserting version information and such (using gmake, of course). The current port Makefile has USES=go and GH_TUPLE, so I think it isn't running the project's Makefile.

Even if it did, though, the project's Makefile calls a Go script that relies on Git to find the version, so it wouldn't work because the port is downloading an archive of the repository, not cloning it with Git. I think there are port Makefile settings to handle this, but I can't find what they are. Hoping someone knows how to do it off the top of their head.
 

diizzy

Aspiring Daemon

Reaction score: 211
Messages: 602

It's only cosmetic as the package itself will carry the correct version number but if you want to fix it you need to patch the Makefile and set version using a different way than using the go script.
 
OP
Y

Yujiri

New Member


Messages: 10

Surely there is a better way to build a port that uses gmake than patching its Makefile. Actually, how would that even help if the project's Makefile isn't being run?

I saw that page in the Handbook, but the problem is that setting version information properly requires cloning the Git repository, which USE_GITHUB doesn't seem to do.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 13,151
Messages: 39,766

Actually, how would that even help if the project's Makefile isn't being run?
Why do you think this matters? Did you take a look at the project's Makefile? If you did you would have noticed it actually uses go to compile the whole thing. All the project's Makefile does is run a couple of go commands.

Look what the Makefile actually does:
Code:
build-quick:
	go build -ldflags "-s -w $(GOVARS) $(ADDITIONAL_GO_LINKER_FLAGS)" ./cmd/micro
Then look at the port's Makefile again, and compare the command with this.
 
OP
Y

Yujiri

New Member


Messages: 10

I did notice this. I mentioned that in my first post. I'm asking if there's a way to make the port Makefile run the project's Makefile using gmake instead of running the Go commands manually (and also clone the repository using Git instead of just downloading a snapshot), to avoid duplicating code between the Makefiles.

The current port Makefile also includes the BUILD_DATE this way, which doesn't make sense since it won't be accurate if you build from ports - the binary would've been built on the current date, not the hardcoded one. This is one of the things the project's Makefile takes care of that I don't want to duplicate (it runs scripts in the repo that get this information).
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 13,151
Messages: 39,766

I'm asking if there's a way to make the port Makefile run the project's Makefile using gmake instead of running the Go commands manually (and also clone the repository using Git instead of just downloading a snapshot), to avoid duplicating code between the Makefiles.
Replace the USES= go with USES= gmake. Make sure to add Go as a build dependency though. Maybe it's needed as a run or library dependency too.

Looking at the history of the port, there's actually a good reason why it does it this way. And you're going to clobber all over that.

 

acheron

Aspiring Daemon
Developer

Reaction score: 344
Messages: 797

I did notice this. I mentioned that in my first post. I'm asking if there's a way to make the port Makefile run the project's Makefile using gmake instead of running the Go commands manually (and also clone the repository using Git instead of just downloading a snapshot), to avoid duplicating code between the Makefiles.
Don't add a useless dependency on gmake please.
 

acheron

Aspiring Daemon
Developer

Reaction score: 344
Messages: 797

You can use this (BUILD_DATE is probably wrong):
Code:
 GO_TARGET=     ./cmd/micro
 GO_BUILDFLAGS= -ldflags "\
                -s -w \
-               -X main.Version=${PORTVERSION} \
-               -X main.CommitHash=${BUILD_HASH} \
-               -X 'main.CompileDate=${BUILD_DATE}'"
+               -X github.com/zyedidia/micro/v2/internal/util.Version=${PORTVERSION} \
+               -X github.com/zyedidia/micro/v2/internal/util.CommitHash=${BUILD_HASH} \
+               -X 'github.com/zyedidia/micro/v2/internal/util.CompileDate=${BUILD_DATE}'"
 
-BUILD_HASH=    1856891
-BUILD_DATE=    August 9, 2018
+BUILD_HASH=    c5b0c2d
+BUILD_DATE=    May 25, 2020
 

acheron

Aspiring Daemon
Developer

Reaction score: 344
Messages: 797

Code:
work/stage/usr/local/bin/micro -version
Version: 2.0.4
Commit hash: c5b0c2d
Compiled on May 25, 2020
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 13,151
Messages: 39,766

Wouldn't that trigger network access during the build phase? That would be a big no-no.
 
OP
Y

Yujiri

New Member


Messages: 10

Well I gave up and opened a PR without a patch (even with gmake, it still wouldn't work without Git cloning the repository) and consensus seems to be that ignoring the project's Makefile and inserting metadata manually is the intended way. PR 247099.

Wouldn't that trigger network access during the build phase? That would be a big no-no.

I didn't think about that. I'm not sure if it actually would, since cloning the repository would happen first and I don't think it does anything else after that, but this makes sense as a rationale for not using the project's Makefile.

Don't add a useless dependency on gmake please.

I did consider this, but my understanding is that it would only be required as a dependency for the port, and not for the package, since the package wouldn't need to be built on the user's system.

So I guess USES=go is the direction this is going after all. That resolves my reason for making this thread, but I would still like to know if there's a way to have a port clone a Git repository (without doing something kludgy like putting it in a target as a shell command). (And yes, I realize that would add a second build dependency on Git.)
 

acheron

Aspiring Daemon
Developer

Reaction score: 344
Messages: 797

So I guess USES=go is the direction this is going after all. That resolves my reason for making this thread, but I would still like to know if there's a way to have a port clone a Git repository (without doing something kludgy like putting it in a target as a shell command). (And yes, I realize that would add a second build dependency on Git.)
You can't clone a git or svn repo at build time since the network is deactivated. What you can do is create an archive with the git metadata and host it somewhere and make the port uses this tarball.
 
Top