Den sön 20 okt. 2024 kl 07:07 skrev Nathan Hartman <hartman.nat...@gmail.com
>:
> On Sat, Oct 19, 2024 at 4:18 PM Daniel Sahlberg <
> daniel.l.sahlb...@gmail.com> wrote:
>
>> Hi,
>>
>> I'd like to make some changes to tools/dev/unix-build/Makefile.svn but
>> I'd like to run then by the community before committing.
>>
>> Makefile.svn is currently hard coding a dependency version by setting
>> (for example)
>> RUBY_VER = 2.7.4
>> and
>> SHA256_${RUBY_DIST} =
>> 3043099089608859fc8cce7f9fdccaa1f53a462457e3838ec3b25a7d609fbc5b
>> (where RUBY_DIST is derived from RUBY_VER)
>>
>> I'd like to add several different SHA256_-sums, for "known" dependency
>> versions:
>> SHA256_ruby-2.7.4.tar.gz =
>> 3043099089608859fc8cce7f9fdccaa1f53a462457e3838ec3b25a7d609fbc5b
>> SHA256_ruby-2.7.7.tar.gz =
>> e10127db691d7ff36402cfe88f418c8d025a3f1eea92044b162dd72f0b8c7b90
>> SHA256_ruby-2.7.8.tar.gz =
>> c2dab63cbc8f2a05526108ad419efa63a67ed4074dbbcf9fc2b1ca664cb45ba0
>> SHA256_ruby-3.0.7.tar.gz =
>> 2a3411977f2850431136b0fab8ad53af09fb74df2ee2f4fb7f11b378fe034388
>>
>> This way it is relatively easy to change a version by changing RUBY_VER
>> to one of the supported versions. To support newer versions one would of
>> course have to add additional SHA256-sums, but it shouldn't be worse than
>> the current situation.
>>
>
>
> I like the idea of saving the SHA256 sums of known versions of
> dependencies. It would be a convenience, because currently, if you wish to
> use a different version than the default, there is a need to calculate the
> sum manually. I've done this a few times. Obviously it will still be
> necessary to do this the first time someone uses a version whose sum hasn't
> been added yet, but only the first time.
>
> By the way, if the dependency version variables were assigned with '?='
> instead of '=', such as:
>
> RUBY_VER ?= 2.7.4
>
> then you could override them at the command line.
>
> *However*, please note that if RUBY_VER happens to be defined in the
> environment, the value of the environment variables would take precedence
> over the value assigned in the makefile even if not assigned on the command
> line. This may or may not be desirable, so using '?=' might be a bad idea.
>
> Personally I'm okay with leaving it as '=' and editing the makefile to
> specify the version of a dependency (e.g., RUBY_VER) if a version different
> than the default is desired, while saving the SHA256 sums for several known
> versions for convenience.
>
> More below:
>
>
> I'd love to factor out the _VER variables to a separate file that is not
>> committed to SVN, best way I could figure out is to let the user create
>> Makefile from a new Makefile.tmpl (instead of symlinking to Makefile.svn)
>> and including unix-build/Makefile.svn from Makefile(.tmpl). This will be a
>> breaking change for thise (few?) using Makefile.svn.
>>
>
>
> I don't understand part of the paragraph above.
>
> I understand the part about factoring out the "known" SHA256 sums to
> another file. This could make sense if there are to be myriad SHA256 sums
> for all of the different dependencies.
>
I'm talking about RUBY_VER (APR_VER, SERF_VER etc.). The SHA256_xxx should
be kept in Makefile.svn.
> However please note that this makefile is used by creating a symlink to it
> (see example usage in adjacent readme) so factoring to a separate file may
> require a second symlink or other handling. Unless we're talking about
> thousands of lines of SHA256 sums, I'd rather leave it as one file -- but
> this is only my opinion given my current understanding (or lack of
> understanding) of your idea.
>
Correctly noted - this was the "breaking change" referenced above. The
existing users would have to remove that symlink and instead `cp
unix-build/Makefile.tmpl Makefile`
I also explored keeping the symlink and instead `include Makefile.ver`, but
it seems Make is creating the targets before reading the included file, so
the target $(PYTHON_OBJDIR)/.retrieved, where PYTHON_OBJDIR =
$(OBJDIR)/python-$(PYTHON_VER), will be expanded without a version number.
The part I don't understand: Why a file that is *not* committed to SVN?
>
Sorry for not making that clear - I realise my explanation got lost in one
of the edits.
What I wanted to achieve is that `svn st` doesn't show Makefile.svn as
modified, just because I want to try out a different version of one of the
dependencies. (Of course, as you rightly note, if that new dependency
require adding a new SHA256 it has to be added to Makefile.svn but I don't
have to force everyone else to use (for example) SWIG 4.3.0beta1).
Makefile.tmpl should of course be committed, to provide default version
numbers.
I also considered using the ?= operator, but discarded that idea for two
reasons:
- To avoid accidentally catching up on environment variables.
- To make it easier to set a version in a file stored on-disk, so I could
come back at a later time and not having to remember (or write down
separately) exactly what dependency versions I was trying out.
Hope that explains!
Cheers,
Daniel
