On 2024-05-03 17:14, Collin Funk wrote:
Also about this comment in intprops-internal.h:
/* This include file assumes that signed types are two's complement without
padding bits; the above macros have undefined behavior otherwise.
If this is a problem for you, please let us k
On 5/3/24 6:03 PM, Bruno Haible wrote:
>> In main.py a call to mkdtemp() was the use of the 'tempfile' module
>> prefix.
>
> Oh, that would have led to a runtime error, right?
Yes, it would only be seen if it entered the section of code where
modules have an incompatible license. So the program w
Hi Collin,
> In main.py a call to mkdtemp() was the use of the 'tempfile' module
> prefix.
Oh, that would have led to a runtime error, right?
Can you please add, to the first line of the ChangeLog entry, a note
that tells us when the regression was introduced? Such as
(regression 2024-xx-xy)
In main.py a call to mkdtemp() was the use of the 'tempfile' module
prefix.
Also, Python seems really good at cleaning up the temporary directory
created with tempfile.TemporaryDirectory() atleast on GNU/Linux.
There might be some ways to interrupt it, or some platform specific
behavior to that.
Hi Paul,
On 5/3/24 2:50 PM, Paul Eggert wrote:
>> The macros for compilers who don't support GCC's builtins are
>> really clever. They don't look like they were too much fun to write
>> though. :)
>
> Actually they were fun in a twisted sort of way. My secret was to not
> work on them more than 3
Collin Funk wrote:
> Maybe intprops.h and the stdckdint.h replacement are worth a mention
> too.
intprops.h is a masterpiece. But Gnulib has more than 1000 modules;
therefore in a history section, we can only mention groups of modules
(like "multithreading", "", etc.). Otherwise it would be too
lo
On 2024-05-03 14:14, Collin Funk wrote:
The macros for compilers who don't support GCC's builtins are
really clever. They don't look like they were too much fun to write
though. :)
Actually they were fun in a twisted sort of way. My secret was to not
work on them more than 30 minutes at a time
On 5/2/24 11:46 PM, Simon Josefsson wrote:
> Nice catch. It doesn't make sense for maint.mk's indentation to be
> influenced by ~/.indent.pro -- the style has to be a per-project
> setting. I pushed the patch below.
Thanks. Inetutils now runs 'make syntax-check' and passes for me.
Collin
Hi Bruno,
On 5/2/24 11:15 AM, Bruno Haible wrote:
> doc: Add appendix about Gnulib history.
> * doc/gnulib-history.texi: New file.
> * doc/gnulib.texi: Include it.
Interesting section, thanks.
> Providing a substitute / override for a system function was relatively easy.
> Prov
Hi Bruno,
On 5/3/24 6:23 AM, Bruno Haible wrote:
> Rationale: If there is a problem with the command-line options,
> there is a certain probability that the cause is the version
> of gnulib-tool. The user may have used an older one, whereas they
> intended to use another one. That
Hi Bruno,
> The patch below fixes it for me. It reverts a workaround for gcc 14.0.1
> from a few days ago, for which I'm adding a different workaround later.
Thank you very much. That fixed the build errors also for us. (Tested with
6213c5bd72d15ca5e1ea9c34122899e02fed448c.)
Markus
Hi Collin,
> In main() of the Python version uses a mix of APP['name'] and
> hard-coded 'gnulib-tool' which is a bit strange.
The short program name is 'gnulib-tool'; the long program name is APP['name'].
They *should* be used as follows:
* When the diagnostic is related to the command-line op
Hi Collin,
> I've attached a patch correcting the program name in this line:
>
> you need to use 'gnulib --import' - at your own risk!
>
> The program name should be 'gnulib-tool'.
Thanks for this correction! Obvious.
Bruno
13 matches
Mail list logo
