[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Erroneous uses of regex in the invokation of FIND-FILES
From: |
Mark H Weaver |
Subject: |
Re: Erroneous uses of regex in the invokation of FIND-FILES |
Date: |
Thu, 22 Aug 2019 16:49:21 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) |
Hi Alex,
Alex Vong <address@hidden> writes:
> I find out that there are a lof of erroneous uses of regex in the
> invokation of FIND-FILES. The correct usage should be:
>
> (find-files "." "\\.c$")
>
> Instead people write:
>
> (find-files "." ".*\\.c")
>
> which match unwanted files.
>
> For examples, in the procedure CUSTOM-GCC, the correct regex should be:
>
> "(c\\+\\+|cpp|g\\+\\+|gcov|gcc|gcc-.*)$"
>
> instead of:
>
> ".*(c\\+\\+|cpp|g\\+\\+|gcov|gcc|gcc-.*)"
>
> Please correct me if I am wrong.
You're right. It would be good to fix these problems incrementally, as
long as the changes don't cause too many rebuilds.
Changes to core packages will need to wait for now, since 'core-updates'
is frozen, and 'core-updates-next' should also be considered frozen,
since it will become 'core-updates' as soon as Berlin has built it out a
bit more. (The only change in 'core-updates-next' relative to
'core-updates' is that the new bootstrap tarballs have been fixed to be
deterministic.)
For some of these fixes, it might be best to apply them to 'staging'.
> Right now, the erroneous use of regex in CUSTOM-GCC casues the 'bin/'
> directory of the output of gccgo, gcc-objc and gcc-objc++ to be empty.
I'm uncertain how many rebuilds it would trigger to change 'custom-gcc',
and I don't have confidence that "guix refresh -l" is capable of giving
us a reliable answer. In the meantime, would you like to file a bug
report for this, so it's not forgotten?
Thanks for looking into it.
Best,
Mark