Parker Moore <[email protected]> writes:
>> the logical place to pull that information from would be
>> ../../GIT-VERSION-FILE,
>
> I agree. It would make more sense to build this to a specific version
> or git revision rather
> than a time. Perhaps that would be a different patch?
It would definitely be a separate (and optional) patch and must come
after "do we use = in between or send var/val as two separate
arguments?" patch. That was what I meant to say with "... would be
version file, but the mechanism to embed it would be the same as
today".
>> So unless the "dynamic lookup in the Makefile" turns out to be too
>> gross, we would want to keep the mechanism and just make it usable
>> for versions before 1.5 and also after 1.7, I would guess.
>
> A dynamic lookup of the go version would look for go 1.0, 1.1, 1.2,
> 1.3, 1.4 and 1.5.0.
> These versions would be incompatible with the `X var=val` syntax. I am
> not too familiar
> with Makefile syntax for numerical comparison, but I believe this
> would be fairly simple.
$ go version
go version go1.3.3 linux/amd64
is what I seem to be locally getting, so I'd imagine it would be
something like this perhaps?
git-remote-persistent-https:
case $$(go version) in \
"go version go"1.[0-5].*) EQ=" " ;; *) EQ="=" ;; esac && \
go build -o git-remote-persistent-https \
-ldflags "-X main._BUILD_EMBED_LABEL$${EQ}$(BUILD_LABEL)"
> Would you like me to whip up a patch for it?
Surely, and thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
