* Erroneous uses of regex in the invokation of FIND-FILES @ 2019-08-22 10:04 Alex Vong 2019-08-22 20:49 ` Mark H Weaver 2019-09-20 20:31 ` Maxim Cournoyer 0 siblings, 2 replies; 5+ messages in thread From: Alex Vong @ 2019-08-22 10:04 UTC (permalink / raw) To: guix-devel [-- Attachment #1: Type: text/plain, Size: 594 bytes --] Hello guix, 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. 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. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 227 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Erroneous uses of regex in the invokation of FIND-FILES 2019-08-22 10:04 Erroneous uses of regex in the invokation of FIND-FILES Alex Vong @ 2019-08-22 20:49 ` Mark H Weaver 2019-08-23 2:50 ` bug#37150: " Alex Vong 2019-09-20 20:31 ` Maxim Cournoyer 1 sibling, 1 reply; 5+ messages in thread From: Mark H Weaver @ 2019-08-22 20:49 UTC (permalink / raw) To: Alex Vong; +Cc: guix-devel Hi Alex, Alex Vong <alexvong1995@gmail.com> 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#37150: Erroneous uses of regex in the invokation of FIND-FILES 2019-08-22 20:49 ` Mark H Weaver @ 2019-08-23 2:50 ` Alex Vong 2019-08-23 3:55 ` Alex Vong 0 siblings, 1 reply; 5+ messages in thread From: Alex Vong @ 2019-08-23 2:50 UTC (permalink / raw) To: 37150 [-- Attachment #1: Type: text/plain, Size: 2020 bytes --] Hello guix, Currently, there are a lot of erroneous uses of regex in the invokation of FIND-FILES. Please see the conversations below (taken from https://lists.gnu.org/archive/html/guix-devel/2019-08/msg00149.html). Mark H Weaver writes: > Hi Alex, > > Alex Vong <alexvong1995@gmail.com> 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 -- Stand with Hong Kong! #Eye4HK Alex https://twitter.com/freedomhkg https://twitter.com/stand_with_hk [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 227 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#37150: Erroneous uses of regex in the invokation of FIND-FILES 2019-08-23 2:50 ` bug#37150: " Alex Vong @ 2019-08-23 3:55 ` Alex Vong 0 siblings, 0 replies; 5+ messages in thread From: Alex Vong @ 2019-08-23 3:55 UTC (permalink / raw) To: 37150 [-- Attachment #1.1: Type: text/plain, Size: 360 bytes --] Hello Mark, >> You're right. It would be good to fix these problems incrementally, as >> long as the changes don't cause too many rebuilds. >> I agree we should fix it incrementally, like how the 'invoke' transition was handled. The patch below does exactly that (it fixes the problem for delta which causes 6 rebuilds only according to "guix refresh -l"). [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1.2: 0001-gnu-delta-Fix-regex-in-the-invokation-of-find-files.patch --] [-- Type: text/x-diff, Size: 1066 bytes --] From cb5f2febd564a2bcb550de537156db59588098c4 Mon Sep 17 00:00:00 2001 From: Alex Vong <alexvong1995@gmail.com> Date: Fri, 23 Aug 2019 11:06:49 +0800 Subject: [PATCH] gnu: delta: Fix regex in the invokation of 'find-files'. See <https://bugs.gnu.org/37150> for more information. * gnu/packages/debug.scm (delta)[arguments]: Fix regex. --- gnu/packages/debug.scm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gnu/packages/debug.scm b/gnu/packages/debug.scm index 82631deef6..e1cba5d3fe 100644 --- a/gnu/packages/debug.scm +++ b/gnu/packages/debug.scm @@ -75,7 +75,7 @@ (begin (for-each (lambda (h) (install-file h doc)) - `("License.txt" ,@(find-files "www" ".*\\.html"))) + `("License.txt" ,@(find-files "www" "\\.html$"))) (for-each (lambda (b) (install-file b bin)) `("delta" "multidelta" "topformflat")))) -- 2.23.0 [-- Attachment #1.3: Type: text/plain, Size: 1219 bytes --] >> 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? >> It would probably cause a world rebuild... I will wait for the next cycle for patch submittion. >> Thanks for looking into it. >> >> Best, >> Mark You're welcomed! -- Stand with Hong Kong! #Eye4HK #BoycottMulan Alex https://twitter.com/freedomhkg https://twitter.com/stand_with_hk [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 227 bytes --] ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: Erroneous uses of regex in the invokation of FIND-FILES 2019-08-22 10:04 Erroneous uses of regex in the invokation of FIND-FILES Alex Vong 2019-08-22 20:49 ` Mark H Weaver @ 2019-09-20 20:31 ` Maxim Cournoyer 1 sibling, 0 replies; 5+ messages in thread From: Maxim Cournoyer @ 2019-09-20 20:31 UTC (permalink / raw) To: Alex Vong; +Cc: guix-devel Hi again, Alex Vong <alexvong1995@gmail.com> writes: > Hello guix, > > 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. > > 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. Looking at this some more, I'm not sure what we expect to see in the bin/ directory of gcc-objc, As I found out earlier, the files present before any deletion are those: --8<---------------cut here---------------start------------->8--- c++ cpp g++ gcc gcc-ar gcc-nm gcc-ranlib gcov gcov-dump gcov-tool x86_64-unknown-linux-gnu-c++ x86_64-unknown-linux-gnu-g++ x86_64-unknown-linux-gnu-gcc x86_64-unknown-linux-gnu-gcc-8.3.0 x86_64-unknown-linux-gnu-gcc-ar x86_64-unknown-linux-gnu-gcc-nm x86_64-unknown-linux-gnu-gcc-ranlib --8<---------------cut here---------------end--------------->8--- All of those files don't appear to be specific to gcc-objc (they are also part of regular gcc) and thus it appear that removing them fits the bill (the patch name says it exists to remove broken or conflicting files). The way that these GCC packages affect the GCC installation is by mean of extending the search path of the GCC libraries, e.g.: --8<---------------cut here---------------start------------->8--- (define-public gcc-objc-5 (custom-gcc gcc-5 "gcc-objc" '("objc") (list (search-path-specification (variable "OBJC_INCLUDE_PATH") (files '("include"))) (search-path-specification (variable "LIBRARY_PATH") (files '("lib" "lib64")))))) --8<---------------cut here---------------end--------------->8--- not by providing custom binaries. Here's the list of files of the regular gcc package: --8<---------------cut here---------------end--------------->8--- ls -l /gnu/store/ginrh3x6qi4w2i005gics37wzz5b78s7-gcc-5.5.0/bin total 9308 c++ cpp g++ gcc gcc-ar gcc-nm gcc-ranlib gcov gcov-dump gcov-tool x86_64-unknown-linux-gnu-c++ x86_64-unknown-linux-gnu-g++ x86_64-unknown-linux-gnu-gcc x86_64-unknown-linux-gnu-gcc-5.5.0 x86_64-unknown-linux-gnu-gcc-ar x86_64-unknown-linux-gnu-gcc-nm x86_64-unknown-linux-gnu-gcc-ranlib --8<---------------cut here---------------end--------------->8--- It's confusing though that an empty bin directory is left behind. We could fix this. Maxim ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-09-20 20:31 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-08-22 10:04 Erroneous uses of regex in the invokation of FIND-FILES Alex Vong 2019-08-22 20:49 ` Mark H Weaver 2019-08-23 2:50 ` bug#37150: " Alex Vong 2019-08-23 3:55 ` Alex Vong 2019-09-20 20:31 ` Maxim Cournoyer
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/guix.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.