guix-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]