* build-aux/bootstrap (gitignore_entries, insert_if_absent)
(insert_vc_ignore, symlink_to_dir): Define these shell functions
before including bootstrap.conf. This is for GNU tar, whose
bootstrap.conf uses symlink_to_dir.
---
ChangeLog | 8 ++
build-aux/bootstrap | 220
In a project that uses Gnulib
1) with a lib/ dir that contains the 'non-recursive-gnulib-prefix-hack'
but not the 'alloca-opt' module,
2) with a tests/ dir that contains the 'alloca-opt' module,
Automake produces an error:
tests/Makefile.am:58: error: required file 'lib/alloca.c' not fo
Currently gnulib-tool has a constraint: If you want the Makefile
in lib/ to be called lib/gnulib.mk, the Makefile in tests/ must be
called tests/gnulib.mk as well. With this patch, it becomes possible
to use tests/Makefile.am instead.
Ideally, we would have two independent options. But that would
Jan,
> > I claim that
> >
> > * Caring about (1), (2), (3) should be done in utility functions outside
> > of
> > realpath(), since they can be useful even on relative file names.
>
> Ah right. If the need arises, I can imagine someone working on a patch
> to factor out "slashify_file_nam
Bruno Haible writes:
Hi!
> Jan Nieuwenhuizen wrote:
>> Yes, but this example shows the mixing of three problems:
>> (1) wrong drive letter casing,
>> (2) difference in type of slash,
>> (3) difference in casing of the file name.
Please find attached a patch that only cares about (2), becau
Hi Marc,
> I'm using build-aux/prefix-gnulib-mk to rewrite the Gnulib Makefile
> fragment so that it can be included by a Makefile in a top-level directory.
>
> What I haven't managed to get working, though, is renaming the Gnulib lib/
> directory at the same time (by setting $source_base in boot
Jan Nieuwenhuizen wrote:
> > the processor that interprets
> > #include "c:/foo.h"
> > #include "C:/FOO.H"
> > #include "C:\\FOO.H"
> > cannot just assume that different file names correspond to different
> > files on disk.
>
> Yes, but this example shows the mixing of three problems:
> (1
Bruno Haible writes:
Hello!
> Jan Nieuwenhuizen wrote:
>> Do you see a cheap way to return the correct casing for the rest of the
>> file name?
>
> No. [1]
Check, thanks.
>> I agree it's quite debatable and a bit arbitrary to correct drive name
>> casing. The reasons why opted to put in after
