Makes sense. I used the function in these gnulib modules that currently do
not have a dependency on basename (i believe): exclude, fts, glob, link,
progname.I noticed for some, like link, they reimplement the basename
functionality (although slightly lacking):
https://github.com/coreutils/gnul
Not thinking of the bigger picture, rather than looking to replicate the
string functionality originally there I should have considered the end goal
before evaluating possible gnulib modules. Will update. This does bring
me back to part of the original question. Right now filename has no
depend
That was my mistake, missed an r in there which also means there is no
gnulib module for strrpbrk or strrcspn. This was used for
the LAST_SLASH_IN_PATH macro I added. I temporarily just added a static
implementation to the header along the lines of:
```
static const char* strrpbrk(const char* s,
Sorry I try to keep up on the mailing list but missed this. I have been
reformatting some of my patches for official submission later this month
but I also handled many of these cases:
https://github.com/mitchcapper/gnulib/compare/master...ours_win_fsusage_fixes?w=1#diff-7e2438152a60cd739a4b33b780
> If I have understood it correctly, the best way to handle file names on
native
> Windows is to
> - use '\\' as a directory separator when composing file names,
> - allow both '/' and '\\' when inspecting file names.
Yes, that is largely what I implemented. There is a platform
specific DIR_SEPA
> The current state is an attempt to make code compile if it doesn't use
> or . I don't know whether this state can be significantly
> improved. But if you have reasonable suggestions, please show them!
For requests to get the actual username I don't know if it is better to:
1) Try the official A
Thanks Bruno for such detailed notes. I will start to work on cleaning up
the patches to prep for the mailing list.
> When a package has complicated fork/exec logic, generally it's advisable
to
> use the posix_spawn facility when possible. This provides not only
portability
> to native Windows; i
> It's nice that you consider enhancing gnulib-tool.py. But don't
underestimate
the task:
Yes, this suggestion was _only_ to support situations where no
automake-subdir was required and we stripped the path.I have automated
several build packages so could likely automate testing of the
gnulib-
I am doing some quick and dirty things currently for compiling a slew of
(mostly) gnu software of Windows. I hope to have some semi-quality
patches to submit soon enough.
I have been very grateful for gnulib-tool.py as it results in some massive
bootstrap speed improvements (over 10x) on Windows
Without this you may get
print('Removing file %s (backup in )' % (path, backup))
^~~~
TypeError: not all arguments converted during string formatting
./bootstrap: gnulib-tool failed
~mitch (they, them)
pygnulib_minor_bug.patch
Description: Bi
10 matches
Mail list logo
