On Tue, Nov 12, 2024 at 09:50:27PM +0100, Patrice Dumas wrote: > On Tue, Nov 12, 2024 at 08:09:58PM +0000, Gavin Smith wrote: > > > > convert/convert_html.c:23:10: fatal error: copy-file.h: No such file or > > directory > > 23 | #include "copy-file.h" > > | ^~~~~~~~~~~~~ > > compilation terminated. > > > > Note this is for copying the JavaScript files with INFO_JS_DIR, which is > > hardly used anyway. > > It is needed and used to setup Javascript to get something similar with > HTML than with the Info reader. Am I missing something?
No, you are not missing anything, copying the files is necessary. I am just saying it should be implemented simply. > > In the worst case, it would be possible to copy a file with fopen on > > a source and destination files, fread from the source file and fwrite > > to the destination file, although this would be more inefficient than > > dedicated file copying functionality. > > I guess that it is what Gnulib copy-file does, but I did not want to > reimplement copying files, which I believe should be some kind of > facility available from library/gnulib code that we should not need to > reimplement and maintain ourselves. The problem with using the Gnulib code, I expect, is that it accounts for all kind of issues that aren't relevant to our use case (e.g. access control lists, file modification dates, preserving owner and permissions). I can't see how it can be that complicated to call fopen/fread/fwrite ourselves to copy the file. These are all completely standard library functions. I can have a go at implementing this in the next couple of days. As Eli found, gnulib redefinitions can often clash with Perl header files on MS-Windows, so reducing the number of gnulib modules for the XS modules would reduce the number of clashes we would have to investigate. > My feeling is that the guid/uid issue is a bug or an issue of Autoconf > that should be fixed there. We can avoid using it, sure, but it seems > to me that it is supposed to work. > > -- > Pat
