PATCH: Previous zsh.yo.in patch wasn't good enough

PATCH: Previous zsh.yo.in patch wasn't good enough

[Bart Schaefer]

Apparently yodl's file-inclusion gets confused if the zsh.yo file is not in
the $(sdir).

My previous patch produced a clean compile but an empty zsh.info; this goes
on top of that one.

Index: Doc/Makefile.in
===================================================================
@@ -78,12 +78,12 @@
 %.info: zsh.texi
 	$(MAKEINFO) $(sdir)/zsh.texi || exit 0
 
-zsh.texi: zsh.yo
+zsh.texi: $(sdir)/zsh.yo
 	$(YODL) -o $(sdir)/zsh.texi -I$(sdir) -w ztexi.yo version.yo zsh.yo
 	test -f $(sdir)/zsh.texi
 
-zsh.yo: zsh.yo.in
-	sed 's,@@TEXINFO@@,texinfo\($(tzsh).info\)\($(tzsh)\),' $(sdir)/zsh.yo.in >zsh.yo
+$(sdir)/zsh.yo: $(sdir)/zsh.yo.in
+	sed 's,@@TEXINFO@@,texinfo\($(tzsh).info\)\($(tzsh)\),' $(sdir)/zsh.yo.in > $(sdir)/zsh.yo
 
 .yo.1:
 	@case $@ in \

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: PATCH: Previous zsh.yo.in patch wasn't good enough

[Zefram]

Bart Schaefer wrote:
>+$(sdir)/zsh.yo: $(sdir)/zsh.yo.in
>+	sed 's,@@TEXINFO@@,texinfo\($(tzsh).info\)\($(tzsh)\),' $(sdir)/zsh.yo.in > $(sdir)/zsh.yo

Bad idea.  The source tree mustn't be modified during building;
you'll have to find some other way to do this.  Isn't it possible to
do that variable replacement in the .texi file, leaving the .yo files
name-independent?

-zefram

Re: PATCH: Previous zsh.yo.in patch wasn't good enough

[Bart Schaefer]

On Dec 3,  9:10am, Zefram wrote:
} Subject: Re: PATCH: Previous zsh.yo.in patch wasn't good enough
}
} Bart Schaefer wrote:
} >+$(sdir)/zsh.yo: $(sdir)/zsh.yo.in
} >+	sed 's,@@TEXINFO@@,texinfo\($(tzsh).info\)\($(tzsh)\),' $(sdir)/zsh.yo.in > $(sdir)/zsh.yo
} 
} Bad idea.  The source tree mustn't be modified during building;

The source tree is already modified during building; all the *.1 files go
in $(sdir)/Doc when the man pages are generated, Etc/FAQ and META-FAQ are
written to the source tree, etc.

} Isn't it possible to
} do that variable replacement in the .texi file, leaving the .yo files
} name-independent?

I'm not sure what you're asking.  The problem is that yodl generates an
empty .info file if the .yo file isn't in the source tree.

If you're asking whether we should get rid of zsh.yo.in again so that
zsh.yo is not a generated file, you'll have to ask Clint.  I'm just
cleaning up after his patches in 8827 and 8841.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: PATCH: Previous zsh.yo.in patch wasn't good enough

[Clint Adams]

> If you're asking whether we should get rid of zsh.yo.in again so that
> zsh.yo is not a generated file, you'll have to ask Clint.  I'm just
> cleaning up after his patches in 8827 and 8841.

It struck me as cleaner/safer to do the substitution in the
.yo rather than the .texi, or worse, the .infos, but I don't
think I'd object as long as the end result is the same.

Re: PATCH: Previous zsh.yo.in patch wasn't good enough

[Zefram]

Bart Schaefer wrote:
>The source tree is already modified during building; all the *.1 files go
>in $(sdir)/Doc when the man pages are generated, Etc/FAQ and META-FAQ are
>written to the source tree, etc.

But they don't get modified during a normal build after unpacking the
source -- those files are already up to date in the source tree, and so
don't get rebuilt.  They do get automatically rebuilt if their source
files change, in which case the source tree has already been modified.

The source tree should not be modified by the build process alone;
building should only modify the source tree if the source has already
been modified.

>If you're asking whether we should get rid of zsh.yo.in again so that
>zsh.yo is not a generated file, you'll have to ask Clint.  I'm just
>cleaning up after his patches in 8827 and 8841.

Yes, I think we should be able to do that.

-zefram

Re: PATCH: Previous zsh.yo.in patch wasn't good enough

[Zefram]

Zefram wrote:
>The source tree should not be modified by the build process alone;
>building should only modify the source tree if the source has already
>been modified.

Which I forgot to explain: if you are doing multiple builds from a single
source tree, there MUST NOT be any build-specific data in the source tree,
otherwise the builds will interfere with each other.

-zefram

Re: PATCH: Previous zsh.yo.in patch wasn't good enough

[Clint Adams]

> The source tree should not be modified by the build process alone;
> building should only modify the source tree if the source has already
> been modified.

So I don't seem to have the original PATCH: Previous zsh.yo.in patch wasn't
good enough, nor does it seem to be on the web mailing list archives.

Why can't zsh.yo be generated in the build directory?

Re: PATCH: Previous zsh.yo.in patch wasn't good enough

[Bart Schaefer]

On Dec 3, 10:55am, Clint Adams wrote:
} Subject: Re: PATCH: Previous zsh.yo.in patch wasn't good enough
}
} > The source tree should not be modified by the build process alone;
} > building should only modify the source tree if the source has already
} > been modified.
} 
} So I don't seem to have the original PATCH: Previous zsh.yo.in patch wasn't
} good enough, nor does it seem to be on the web mailing list archives.

Original was 8857, "PATCH: zsh.yo not properly generated from zsh.yo.in"

} Why can't zsh.yo be generated in the build directory?

When zsh.yo is in the separate build directory, the zsh.info generated
from zsh.texi is empty except for the comment that it was generated by
makeinfo.  I tried rebuilding from clean and got the same result; the
trace output from "yodl" indicated that it wasn't reading any of the
$(sdir)/Doc/Zsh/*.yo files.  When I relocated zsh.yo back to the source
tree, everything worked.

Maybe there's just some include-path thing going on that I missed.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: PATCH: Previous zsh.yo.in patch wasn't good enough

[Clint Adams]

> Maybe there's just some include-path thing going on that I missed.

Maybe.  I suppose another ugly solution is to cp all the .yos to the
build directory.

Re: PATCH: Previous zsh.yo.in patch wasn't good enough

[Bart Schaefer]

On Dec 3,  3:48pm, Zefram wrote:
} Subject: Re: PATCH: Previous zsh.yo.in patch wasn't good enough
}
} Zefram wrote:
} >The source tree should not be modified by the build process alone;
} >building should only modify the source tree if the source has already
} >been modified.
} 
} Which I forgot to explain: if you are doing multiple builds from a single
} source tree, there MUST NOT be any build-specific data in the source tree,
} otherwise the builds will interfere with each other.

My thought (which I now see to have been half-formed) was that the docs
were architecture-independent and hence the same for all builds -- but
of course it's possible to have two build trees with different name
transforms.

This leads me to conclude that the $(tzsh).info change is either going
too far, or not far enough:  If we're renaming zsh.info, why aren't we
renaming zsh.1 and zshall.1 and zshbuiltins.1 etc?  And if we're going
to rename those, then they have to be written to the build tree and not
to the source tree, as well.

I *think* -- based on looking at automake-generated Makefile.in files --
that program name transforms are intended strictly as an install-time
thing, and should not affect compile-time file generation.  Its too bad
that info format requires the files to reference their own names.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: PATCH: Previous zsh.yo.in patch wasn't good enough

[Zefram]

Bart Schaefer wrote:
>My thought (which I now see to have been half-formed) was that the docs
>were architecture-independent and hence the same for all builds

They are.  There used to be some configure-specific variable
interpolations, but they were all removed so that the documentation would
be the same everywhere.  This is a necessity, because we can't rely on the
availability of yodl to build a localised version of the documentation.
It is also useful in that people can refer to "page <X> of the Z Shell
Manual" and so on.

>of course it's possible to have two build trees with different name
>transforms.

Yes.  So far that's the only reason why we now need localised
documentation.

>This leads me to conclude that the $(tzsh).info change is either going
>too far, or not far enough:  If we're renaming zsh.info, why aren't we
>renaming zsh.1 and zshall.1 and zshbuiltins.1 etc?

Yes, we should.

>I *think* -- based on looking at automake-generated Makefile.in files --
>that program name transforms are intended strictly as an install-time
>thing, and should not affect compile-time file generation.  Its too bad
>that info format requires the files to reference their own names.

This suggests that we can do the variable replacement on the .texi file,
and then change the names only in the install.  We'd have the .yo files
generating zsh.texi.in in the source tree, and that gets distributed.
Then a sed over that generates zsh.texi in the build tree, with the
transformed name in the appropriate place.  We run makeinfo on that.
Then rename everything (executable, man pages, info files) as its being
installed.

We should probably also rename the lib directory, though this would
require additional effort to compile the transformed name into the
executable.  Same for the share directory.

-zefram

Re: PATCH: Previous zsh.yo.in patch wasn't good enough

[Bart Schaefer]

On Dec 5, 12:34pm, Zefram wrote:
} Subject: Re: PATCH: Previous zsh.yo.in patch wasn't good enough
}
} Bart Schaefer wrote:
} >This leads me to conclude that the $(tzsh).info change is either going
} >too far, or not far enough:  If we're renaming zsh.info, why aren't we
} >renaming zsh.1 and zshall.1 and zshbuiltins.1 etc?
} 
} Yes, we should.

I'm actually beginning to think we *shouldn't*, not even for the info.

} >[...] program name transforms are intended strictly as an install-time
} >thing, and should not affect compile-time file generation.  Its too bad
} >that info format requires the files to reference their own names.
} 
} This suggests that we can do the variable replacement on the .texi file,
} and then change the names only in the install.

If the only line that needs to change is the @setfilename line, then this
might be possible.

} We'd have the .yo files
} generating zsh.texi.in in the source tree, and that gets distributed.
} Then a sed over that generates zsh.texi in the build tree, with the
} transformed name in the appropriate place.  We run makeinfo on that.

The easiest way to do this is to get rid of the "%.info: $(tzsh).texi"
rule and simply have "install.info: $(sdir)/zsh.texi.in".  Otherwise we
have to generate the transformed program name for purposes of determining
the make targets and dependencies, which is painful (as Clint's trick of
calling "make -f - <<EOF" from configure has demonstrated).

} We should probably also rename the lib directory, though this would
} require additional effort to compile the transformed name into the
} executable.  Same for the share directory.

Ick.  This is enough to make me want to back off the name transformations
entirely.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: PATCH: Previous zsh.yo.in patch wasn't good enough

[Bart Schaefer]

On Dec 5,  4:56pm, I wrote:
}
} } Then a sed over that generates zsh.texi in the build tree, with the
} } transformed name in the appropriate place.  We run makeinfo on that.
} 
} The easiest way to do this is to get rid of the "%.info: $(tzsh).texi"
} rule and simply have "install.info: $(sdir)/zsh.texi.in".

Two things:

First, of course I mean "install.info: zsh.texi" and have another rule
for generating zsh.texi from zsh.texi.in.

Second, it just occurred to me that having program name transforms apply
to the documentation changes the results of "make targz-doc" from the top
level directory; in fact, without hacking .distfiles during the build,
"make targz-doc" won't work at all with a transformed program name.

Maybe that's OK, as we don't really want someone distributing a tar file
with transformed names in the documentation, but it's a point to note.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: PATCH: Previous zsh.yo.in patch wasn't good enough

[Zefram]

Bart Schaefer wrote:
>Second, it just occurred to me that having program name transforms apply
>to the documentation changes the results of "make targz-doc" from the top
>level directory; in fact, without hacking .distfiles during the build,
>"make targz-doc" won't work at all with a transformed program name.

This is a good, but not conclusive, argument against doing name
transformations for the documentation: we want the documentation tarball
to be build-independent.  OTOH, we can reasonably assume that developers
will not use a transformed name to build it.

We should build all documentation using the untransformed name.
This makes the files that go into -doc.tar.gz.  The only exception to
this is the info files, which need to be rebuilt if the name changes.
I think we can reasonably distribute zsh.texi as we used to, with
zsh.info(|-<->) in -doc.tar.gz, and then have an extra rule that if
building with a transformed name, then the info files *also* get built
with the transformed name, and it is those info files that get installed.

-zefram

Re: PATCH: Previous zsh.yo.in patch wasn't good enough

[Zefram]

Bart Schaefer wrote:
>} We should probably also rename the lib directory, though this would
>} require additional effort to compile the transformed name into the
>} executable.  Same for the share directory.
>
>Ick.  This is enough to make me want to back off the name transformations
>entirely.

It's not too bad.  These pathnames are already variable.

The purpose of program name transformations is to avoid clashes with
other programs of the same name.  In the case of zsh, this is only likely
to be a clash with another installation of zsh, but it's still a need.
(For example, one of the places where I used to install zsh regularly
is now required to avoid clashes with the names of system-installed
programs -- including the system's zsh 2.4 installation.)  The clash can
apply to lib directories just as it can to binary names, where there are
multiple installations with the same pathname prefix.  We really should
apply the transform to *all* installed filenames.

-zefram