| Message ID | 239ffa690cc0bf65e2ee7fbdbb9c481499e37020.1568309119.git.liu.denton@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Makefile: run coccicheck on all non-upstream sources | expand |
Denton Liu <liu.denton@gmail.com> writes: > Unify the two possible invocations in $(FIND_SOURCE_FILES) by using sed > to remove the `./` prefix in the $(FIND) case. > diff --git a/Makefile b/Makefile > index b88b42d7ed..e2c693440b 100644 > --- a/Makefile > +++ b/Makefile > @@ -2610,6 +2610,7 @@ FIND_SOURCE_FILES = ( \ > -o \( -name 'trash*' -type d -prune \) \ > -o \( -name '*.[hcS]' -type f -print \) \ > -o \( -name '*.sh' -type f -print \) \ > + | sed -e 's|^\./||' \ > ) > > $(ETAGS_TARGET): FORCE An extra process and piping is a bit unfortunate, but this is purely a fallback position where it does not matter too much to expend one-shot overhead; it would only be needed until the user has a working "git ls-files" and starts hacking on our codebase, as this is used only by the xtags targets, which are only for developers. Thanks. Will queue.
On Thu, Sep 12, 2019 at 10:28:32AM -0700, Denton Liu wrote: > Currently, $(FIND_SOURCE_FILES) has two modes: if `git ls-files` is > present, it will use that to enumerate the files in the repository; else > it will use `$(FIND) .` to enumerate the files in the directory. > > There is a subtle difference between these two methods, however. With > ls-files, filenames don't have a leading `./` while with $(FIND), they > do. This does not currently pose a problem but in a future patch, we > will be using `filter-out` to process the list of files with the > assumption that there is no prefix. > > Unify the two possible invocations in $(FIND_SOURCE_FILES) by using sed > to remove the `./` prefix in the $(FIND) case. > > Signed-off-by: Denton Liu <liu.denton@gmail.com> > --- > Makefile | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Makefile b/Makefile > index b88b42d7ed..e2c693440b 100644 > --- a/Makefile > +++ b/Makefile > @@ -2610,6 +2610,7 @@ FIND_SOURCE_FILES = ( \ > -o \( -name 'trash*' -type d -prune \) \ > -o \( -name '*.[hcS]' -type f -print \) \ > -o \( -name '*.sh' -type f -print \) \ > + | sed -e 's|^\./||' \ Ramsay pointed out to me (in an off-list email) that the list of library header files is generated in a similar way, and then those leading './' have to be removed later. See how the LIB_H and CHK_HDRS variables are assigned. I think it would be great to apply the same treatment there, too, to eliminate those './' prefixes right at the source.
diff --git a/Makefile b/Makefile index b88b42d7ed..e2c693440b 100644 --- a/Makefile +++ b/Makefile @@ -2610,6 +2610,7 @@ FIND_SOURCE_FILES = ( \ -o \( -name 'trash*' -type d -prune \) \ -o \( -name '*.[hcS]' -type f -print \) \ -o \( -name '*.sh' -type f -print \) \ + | sed -e 's|^\./||' \ ) $(ETAGS_TARGET): FORCE
Currently, $(FIND_SOURCE_FILES) has two modes: if `git ls-files` is present, it will use that to enumerate the files in the repository; else it will use `$(FIND) .` to enumerate the files in the directory. There is a subtle difference between these two methods, however. With ls-files, filenames don't have a leading `./` while with $(FIND), they do. This does not currently pose a problem but in a future patch, we will be using `filter-out` to process the list of files with the assumption that there is no prefix. Unify the two possible invocations in $(FIND_SOURCE_FILES) by using sed to remove the `./` prefix in the $(FIND) case. Signed-off-by: Denton Liu <liu.denton@gmail.com> --- Makefile | 1 + 1 file changed, 1 insertion(+)