build from source

build from source

[Ray Andrews]

... seems to have gone fairly well, I have an executable (5.9.0.1-dev) but:

cp: cannot stat './Doc/help.txt': No such file or directory

... doesn't sound serious however that file does exist and contains:

  % cat help.txt
exit bye
cd chdir
typeset declare
typeset float
fc history
typeset integer
typeset local
exit logout
print pushln
fc r
typeset readonly
hash rehash
whence type
unhash unalias
unhash unfunction
whence where
whence which
----------------------------------------------------------------

% make
% make check

**************************************
64 successful test scripts, 1 failure, 2 skipped
**************************************
make[1]: *** [Makefile:190: check] Error 1
make[1]: Leaving directory '/aWorking/Zsh/Zsh-5.9/code/Test'
make: *** [Makefile:263: check] Error 2

... scanning back over the output:

Test ./C02cond.ztst failed: bad status 1, expected 0 from:
   [[ $newnewnew -nt $zlnfs && ! ($unmodified -nt $zlnfs) ]]
Was testing: -nt cond
./C02cond.ztst: test failed.

... so one failure that I can see.  Can I follow up on that?  I haven't 
done this for many years but I think I remember that last time I had one 
error as well but we fixed it.

Re: build from source

[Bart Schaefer]

This is more of a zsh-workers than -users thing but I'll try to give a
short and not too technical answer.

On Thu, Feb 1, 2024 at 2:31 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> cp: cannot stat './Doc/help.txt': No such file or directory
>
> ... doesn't sound serious however that file does exist

I believe this error is trying to copy a newly built help.txt from a
temporary location into the spot where you find one existing.

In order to build help.txt you need both "man" and "perl" installed,
as I recall, plus "yodl" to build the input for "man".

> % make check
>
> Test ./C02cond.ztst failed: bad status 1, expected 0 from:
>    [[ $newnewnew -nt $zlnfs && ! ($unmodified -nt $zlnfs) ]]
> Was testing: -nt cond
> ./C02cond.ztst: test failed.

This is checking whether the "file A is newer than file B" test works
properly.  If you're building on Cygwin or the build directory is on a
remote mounted file system, this frequently fails because the file
creation timestamps may be off.

You can run

% ZTST_continue=1 make check TESTNUM=C02

to have it check the remainder of C02cond just in case there's
anything else failing, otherwise this is likely safe to ignore.

Re: build from source

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 1596 bytes --]

> In order to build help.txt you need both "man" and "perl" installed,
as I recall, plus "yodl" to build the input for "man".

No yodl here.  But my next step was to get all the help stuff installed, that seems the most complicated thing.  INSTALL says you can just grab everything pre-cooked 'at the same place as the source' but how you get there is not clear since "git:// ..." isn't viewable in a browser.  Is there an easy way?  Or I'll just grab yodl and do it the hard way.

On 2024-02-01 15:15, Bart Schaefer wrote:
> % ZTST_continue=1 make check TESTNUM=C02


Test ./C02cond.ztst failed: bad status 1, expected 0 from:
   [[ $newnewnew -nt $zlnfs && ! ($unmodified -nt $zlnfs) ]]
Was testing: -nt cond
./C02cond.ztst: test failed.
Test ./C02cond.ztst failed: bad status 1, expected 0 from:
   [[ $zlnfs -ot $newnewnew && ! ($zlnfs -ot $unmodified) ]]
Was testing: -ot cond
./C02cond.ztst: test failed.

... so it's looks like two errors very similar.  Ignore?

Question, after getting the help done, next thing is 'make install', now 
will that overwrite my existing 5.8?  I don't anticipate any issues with 
5.9 but if possible I'd like to keep 5.8 there in reserve, so prevent 
any overwrites of, say, the stuff in /usr/share.../  or wherever else.  
I'm pretty sure I've done that previously -- kept the new and the old 
side by side.  But not if it will be any trouble -- 5.9 isn't going to 
give me problems I don't think.  OTOH, If I'm running the very latest 
build there's always that chance and I have to fire up an older version 
due to some bug in the very latest.




[-- Attachment #2: Type: text/html, Size: 2277 bytes --]

Re: build from source

[Bart Schaefer]

On Thu, Feb 1, 2024 at 5:37 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> No yodl here.  But my next step was to get all the help stuff installed, that seems the most complicated thing.  INSTALL says you can just grab everything pre-cooked 'at the same place as the source'

That assumes you downloaded a tarball.  Very little about INSTALL
applies to building from git export.

> Is there an easy way?  Or I'll just grab yodl and do it the hard way.

No easy way until we actually do a release.

> Test ./C02cond.ztst failed: bad status 1, expected 0 from:
>   [[ $newnewnew -nt $zlnfs && ! ($unmodified -nt $zlnfs) ]]
> Was testing: -nt cond
> ./C02cond.ztst: test failed.
> Test ./C02cond.ztst failed: bad status 1, expected 0 from:
>   [[ $zlnfs -ot $newnewnew && ! ($zlnfs -ot $unmodified) ]]
> Was testing: -ot cond
> ./C02cond.ztst: test failed.
>
> ... so it's looks like two errors very similar.  Ignore?

Yes, the "older than" error is just the reverse of "newer than".

> Question, after getting the help done, next thing is 'make install', now will that overwrite my existing 5.8?

It may replace the binary that's named "zsh" but will leave behind one
named "zsh-5.8" (you should check that exists before running "make
install").  I don't know where/how you got your 5.8 install so "make
install" from source might use completely different directory paths
and everything from both will hang around.

Re: build from source

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 1734 bytes --]


On 2024-02-01 18:08, Bart Schaefer wrote:
> That assumes you downloaded a tarball.  Very little about INSTALL
> applies to building from git export.

Yeah, it does presuppose the tarball.  So I grabbed 5.9 from sourceforge 
and tried again.  With yodl installed that './Doc/help.txt' is not 
complained about, however its contents are exactly the same.  Seems not 
what one might expect to see in a 'help.txt' sort of file but I suppose 
there's a reason:  Those are like aliases, no?

exit bye
cd chdir
typeset declare
typeset float
fc history
typeset integer
typeset local
exit logout
print pushln
fc r
typeset readonly
hash rehash
whence type
unhash unalias
unhash unfunction
whence where
whence which
-----------------------------

The 'C02' test reports the same error.  I'm tempted to fiddle with a 
copy of the test and see just what's going on there.  I doubt anything 
is really broken, as you say.

% make install.info

... reports:

/bin/sh: 4: makeinfo: not found
make[1]: *** [Makefile:498: install.info] Error 1
make[1]: Leaving directory '/aWorking/Zsh/zsh-5.9/Doc'
make: *** [Makefile:255: install.info] Error 2

Debian has no such thing as 'makeinfo' but it does have 'install-info' 
and file 'INSTALL' does say:

If the programme install-info is available, "make install.info" will
insert an entry in the file "dir" in the same directory as the info ...

... so is the script looking for the wrong program?  I edited the script 
as shown on the screen but with the above edit and it exited the 
terminal (as expected) but 'info' still reports version 5.8.  So nothing 
broke at least.  I expect that 'make' handles that script in a more 
sophisticated way than I can duplicate.

But all else seems well.



[-- Attachment #2: Type: text/html, Size: 2633 bytes --]

Re: build from source

[Oliver Kiddle]

Ray Andrews wrote:
>
> The 'C02' test reports the same error.  I'm tempted to fiddle with a copy of
> the test and see just what's going on there.  I doubt anything is really
> broken, as you say.

It is fairly easy to replicate. Use stat to examine the timestamps. The
test is reliant on the underlying filesystem. I know to avoid builds in
my home directory which is typically NFS and prefer a local scratch
filesystem which will also be faster. Use df -T . to see the type of
filesystem for the current directory.

> /bin/sh: 4: makeinfo: not found
> make[1]: *** [Makefile:498: install.info] Error 1
> make[1]: Leaving directory '/aWorking/Zsh/zsh-5.9/Doc'
> make: *** [Makefile:255: install.info] Error 2
>
> Debian has no such thing as 'makeinfo' but it does have 'install-info' and file
> 'INSTALL' does say:

  apt install texinfo

Debian's website has a very useful feature for searching by file
contents.

https://packages.debian.org/cgi-bin/search_contents.pl?word=makeinfo&searchmode=searchfiles&case=insensitive&version=unstable&arch=i386

Or you can install and setup command-not-found

For building zsh (or anything) from source, getting all the dependencies
installed tends to be easier than digging into Makefiles to skip
non-essentials.

It'd be really good to get more testing of the current git head. There
have been quite a few changes and it'd be good to find any regressions
before a release.

Oliver

Re: build from source

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]


On 2024-02-02 09:08, Oliver Kiddle wrote:
>> It is fairly easy to replicate. Use stat to examine the timestamps. The
>> test is reliant on the underlying filesystem. I know to avoid builds in
>> my home directory which is typically NFS and prefer a local scratch
>> filesystem which will also be faster. Use df -T . to see the type of
>> filesystem for the current directory.

That's way above my pay grade.  I'll take a look tho:

% df -T .
Filesystem     Type 1K-blocks  Used Available Use% Mounted on
/dev/sda3      ext4    287237 98929    168852  37% /aWorking


>    apt install texinfo
Installed.  No error msg.  However 'info zsh' still reports 5.8.
> Or you can install and setup command-not-found
Interesting!
>
> For building zsh (or anything) from source, getting all the dependencies
> installed tends to be easier than digging into Makefiles to skip
> non-essentials.
>
> It'd be really good to get more testing of the current git head. There
> have been quite a few changes and it'd be good to find any regressions
> before a release.
Happy to help.
>
> Oliver
>

[-- Attachment #2: Type: text/html, Size: 2280 bytes --]

Re: build from source

[Ray Andrews]

On 2024-02-02 08:14, Ray Andrews wrote:
> If the programme install-info is available, "make install.info" will
>
> insert an entry in the file "dir" in the same directory as the info ...
>
Weeell, all my info files are in '/usr/share/info' and they end in .gz 
and can't be viewed as text.  New zsh info files are in 
'/usr/local/share/info' all by themselves and they are viewable. ( .gz = 
zipped yes?  So info is happy either way it seems).

% info zsh'

... still shows 5.8 version, but

% info /usr/local/share/info/zsh

... shows 5.9 version.  Funny thing is that 'dir' in '/usr/share/info' 
has been updated so it would seem that it's anticipating an update to 
the main info tree, but all the files are old.  Is there a manual fix 
for this?  If not:

#zhelp() { info zsh $1 }
zhelp() { info /usr/local/share/info/zsh $1 }

... seems perfectly workable.

Re: build from source

[Bart Schaefer]

On Fri, Feb 2, 2024 at 3:08 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> On 2024-02-02 08:14, Ray Andrews wrote:
> > If the programme install-info is available, "make install.info" will
> >
> > insert an entry in the file "dir" in the same directory as the info ...
> >
> Weeell, all my info files are in '/usr/share/info' and they end in .gz

That would be from your OS distribution zsh package.

> New zsh info files are in
> '/usr/local/share/info' all by themselves and they are viewable.

The default install path for packages NOT provided by the OS vendor is
under /usr/local, yes.

> ( .gz = zipped yes?  So info is happy either way it seems).

Using "gzip" (GNU zip) rather than "zip", yes.

> ... shows 5.9 version.  Funny thing is that 'dir' in '/usr/share/info'
> has been updated so it would seem that it's anticipating an update to
> the main info tree, but all the files are old.  Is there a manual fix
> for this?

https://www.emacswiki.org/emacs/InfoPath

The "info" program should recognize the equivalent.

Re: build from source

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 1056 bytes --]


On 2024-02-03 14:27, Bart Schaefer wrote:
> That would be from your OS distribution zsh package.

Right, I know these paths vary between distros, not zsh's problem.


> The default install path for packages NOT provided by the OS vendor is
> under /usr/local, yes.
Ok, so it's not an issue that distro info and user installed info are in 
different places.  No problem to solve.
>> ... shows 5.9 version.  Funny thing is that 'dir' in '/usr/share/info'
>> has been updated so it would seem that it's anticipating an update to
>> the main info tree, but all the files are old.  Is there a manual fix
>> for this?
> https://www.emacswiki.org/emacs/InfoPath
>
> The "info" program should recognize the equivalent.
>
Tx.  Sounds like a nothing burger all round.

So the remaining questions are whether it's safe to run a dev build 
within a stock 5.9 -- Lawrence seems to say so -- or whether to fret 
about dependencies or no need.  And what's the git command to grab the 
latest and build it?  I trust it will be simpler than installing from 
scratch.


[-- Attachment #2: Type: text/html, Size: 2218 bytes --]

Re: build from source

[Lawrence Velázquez]

On Sat, Feb 3, 2024, at 6:42 PM, Ray Andrews wrote:
> So the remaining questions are whether it's safe to run a dev build 
> within a stock 5.9

What do you mean by this?

-- 
vq

Re: build from source

[Ray Andrews]

On 2024-02-03 17:26, Lawrence Velázquez wrote:
> On Sat, Feb 3, 2024, at 6:42 PM, Ray Andrews wrote:
>> So the remaining questions are whether it's safe to run a dev build
>> within a stock 5.9
> What do you mean by this?

Can I just build the latest core (if that's the right word) and not 
worry about anything else in the distribution, like functions.  It could 
be a naive question.  I expect that I can, but in Linux dependencies are 
a huge issue so it could be that, say, some function requires some 
particular build or something of that nature.  Or some library or 
other.  But again, I expect there will be no problems.  The main 
executable is self-contained, yes?



>

Re: build from source

[Lawrence Velázquez]

On Thu, Feb 1, 2024, at 8:36 PM, Ray Andrews wrote:
> Question, after getting the help done, next thing is 'make install', 
> now will that overwrite my existing 5.8?  I don't anticipate any issues 
> with 5.9 but if possible I'd like to keep 5.8 there in reserve, so 
> prevent any overwrites of, say, the stuff in /usr/share.../  or 
> wherever else.  I'm pretty sure I've done that previously -- kept the 
> new and the old side by side.  But not if it will be any trouble -- 5.9 
> isn't going to give me problems I don't think.  OTOH, If I'm running 
> the very latest build there's always that chance and I have to fire up 
> an older version due to some bug in the very latest.

It's not a great idea to make the unstable dev build your primary
shell.  If you just want to have it around for testing, you can run
it directly out of the build directory when needed.  (This is what
I do.)

-- 
vq

Re: build from source

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]


On 2024-02-01 22:00, Lawrence Velázquez wrote:
> It's not a great idea to make the unstable dev build your primary
> shell.  If you just want to have it around for testing, you can run
> it directly out of the build directory when needed.  (This is what
> I do.)

I have the same thing in mind -- I'll run the 'dev' just to see if I can 
make myself useful possibly sniffing out a bug, but I want the stable 
release to fall back to in case of trouble.  I'm unclear as to the 
situation with all the rest of whatever files might be associated with 
the 'dev' tho.  It's easy to just run the executable, but I'd worry 
about some other change somewhere else in the project that might be a 
dependency -- or is that not going to be an issue?  And then there's, 
say, Bart's, recent edit to 'zmv' -- will such things be included in a 
'git' of the latest? 'make install' does the Linux thing and distributes 
files here and there, which is standard, but ... well I dunno, maybe 
there's nothing to worry about, but one might suppose that two complete 
installations would be required -- one stable and one bleeding edge.  Or 
not.  Maybe just the executable is the only thing that varies 
'dangerously'.  None of this is obvious.




[-- Attachment #2: Type: text/html, Size: 1981 bytes --]