On Sun, Oct 20, 2024 at 7:17 AM Daniel Sahlberg <daniel.l.sahlb...@gmail.com>
wrote:
> 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.
>
Ah, thanks for clarifying. Continuing to reply inline below...
>
>> 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`
>
Does anything now prevent copying, rather than symlinking, the 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.
>
Wait, make reads targets before includes? That doesn't sound right.
According to the GNU Make manual, "The include directive tells make to
suspend reading the current makefile and read one or more other makefiles
before continuing." [1]
Perhaps something else made it appear that targets were read first?
Variables didn't end up being set due to some syntax error? Wrong file got
included?
>
> 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
>
>
Yes, now I understand better. I am surprised that make didn't read the
included file as expected but I think there was some other error there.
[1]
https://www.gnu.org/software/make/manual/html_node/Include.html
