Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>> On Tue, 16 Jan 2024 11:00:13 -0800, Keith Thompson wrote:
>>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>>> [...]
>>>> Or, if you want to specify the section (given that some
>>>> sections have man pages with names that you might find
>>>> in other sections):
>>>>
>>>> man section manpage
>>>>
>>>> as in
>>>> man 1 mktemp
>>>> which describes the program "mktemp", vs
>>>> man 3 mktemp
>>>> which describes the library function "mktemp()"
>>>
>>> You can also type
>>> man mktemp.1
>>> or
>>> man mktemp.3
>>
>> That only works if there's a file called "mktemp.1"
>> (or "mktemp.3") in your local directory, at least
>> for the version of man(1) that I have available.
>
>Interesting.
>
>I have man 2.20.1 on Ubuntu, provided by the "man-db" package.

It doesn't work that way on my ancient Fedora 20 install (mandb-2.6.5-6)

It does work that way on my Ubuntu 18 install (man-db-2.8.3)

On Tue, 16 Jan 2024 16:13:36 GMT, Scott Lurndal wrote:

> @$(QUIET) || echo " BUILDPDF $@" $(HUSHCOMPILE)groff -t -man $< | ps2pdf - > $@

Why, can’t your groff installation generate PDF directly?

On Tue, 16 Jan 2024 11:23:52 -0800, Keith Thompson wrote:

> I have man 2.20.1 on Ubuntu, provided by the "man-db" package.
> "man mktemp.1" will look up the corresponding man page in $MANPATH.

It also works if the file is mktemp.1.gz.

> If I want to use a local file, I can use an absolute or relative path
> with a '/' in it, such as "man ./mktemp.1".

Yup. Or the “-l” option.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Tue, 16 Jan 2024 16:13:36 GMT, Scott Lurndal wrote:
>
>> @$(QUIET) || echo " BUILDPDF $@" $(HUSHCOMPILE)groff -t -man $< | ps2pdf - > $@
>
>Why, can’t your groff installation generate PDF directly?

It couldn't when I first wrote this rule a couple of decades ago.

Den 2024-01-16 skrev BGB <cr88192@gmail.com>:
> Things like CMake and Ninja seemed to work effectively in the past from
> what little I had used them...
>

As a long time user of CMake, I think it works very well and I use it
for most of my projects, even if they're small. The most simple for I
use is usually

cmake_minimum_required(VERSION $my_installed_version)
project($project_name)

add_executable($output_binay $source_files)

Replace the $-variables with actual values. I like it even for simple
things because it gives me make, make install and make clean or ninja
equivalents with three lines.

That said, CMake is extremely flexible so it's very easy to write
shitty CMake that's very fragile and complex. I know some projects
have replaced CMake with Meson for that reason.

Den 2024-01-16 skrev Andreas Kempe <kempe@lysator.liu.se>:
> Den 2024-01-16 skrev BGB <cr88192@gmail.com>:
>> Things like CMake and Ninja seemed to work effectively in the past from
>> what little I had used them...
>>
>
> As a long time user of CMake, I think it works very well and I use it
> for most of my projects, even if they're small. The most simple for I
> use is usually
>
> cmake_minimum_required(VERSION $my_installed_version)
> project($project_name)
>
> add_executable($output_binay $source_files)
>
> Replace the $-variables with actual values. I like it even for simple
> things because it gives me make, make install and make clean or ninja
> equivalents with three lines.

A small correction. To get make install support a fourth line is
needed

install(TARGETS $output_binary)

>
> That said, CMake is extremely flexible so it's very easy to write
> shitty CMake that's very fragile and complex. I know some projects
> have replaced CMake with Meson for that reason.

On Tue, 16 Jan 2024 22:55:55 GMT, Scott Lurndal wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>>Why, can’t your groff installation generate PDF directly?
>
> It couldn't when I first wrote this rule a couple of decades ago.

Here’s how I get a nicely typeset view of one of my own man pages:

groff -ktman -Tpdf «troff-file» | okular - &

On 17/01/2024 07:04, Scott Lurndal wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>>> On Tue, 16 Jan 2024 11:00:13 -0800, Keith Thompson wrote:
>>>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>>>> [...]
>>>>> Or, if you want to specify the section (given that some
>>>>> sections have man pages with names that you might find
>>>>> in other sections):
>>>>>
>>>>> man section manpage
>>>>>
>>>>> as in
>>>>> man 1 mktemp
>>>>> which describes the program "mktemp", vs
>>>>> man 3 mktemp
>>>>> which describes the library function "mktemp()"
>>>>
>>>> You can also type
>>>> man mktemp.1
>>>> or
>>>> man mktemp.3
>>>
>>> That only works if there's a file called "mktemp.1"
>>> (or "mktemp.3") in your local directory, at least
>>> for the version of man(1) that I have available.
>>
>> Interesting.
>>
>> I have man 2.20.1 on Ubuntu, provided by the "man-db" package.
>
> It doesn't work that way on my ancient Fedora 20 install (mandb-2.6.5-6)
>
> It does work that way on my Ubuntu 18 install (man-db-2.8.3)
>
Hmm, Solaris 11.4, the first few lines of "man man":

NAME
man - find and display reference manual pages

SYNOPSIS
man [-] [-adFlrt] [-M path] [-T macro-package] [-s section] name...

man [-M path] [-s section] -k query...

man [-M path] -f file...

man [-M path] [-s section] -K query...

Still very SysV, but it does use groff now. :-)

For those who want to see the full version:
<https://docs.oracle.com/cd/E88353_01/html/E37839/man-1.html>

Cheers,
Gary B-)

On 17/01/2024 00:32, Andreas Kempe wrote:
> Den 2024-01-16 skrev BGB <cr88192@gmail.com>:
>> Things like CMake and Ninja seemed to work effectively in the past from
>> what little I had used them...
>>
>
> As a long time user of CMake, I think it works very well and I use it
> for most of my projects, even if they're small. The most simple for I
> use is usually
>
> cmake_minimum_required(VERSION $my_installed_version)
> project($project_name)
>
> add_executable($output_binay $source_files)
>
> Replace the $-variables with actual values. I like it even for simple
> things because it gives me make, make install and make clean or ninja
> equivalents with three lines.
>
> That said, CMake is extremely flexible so it's very easy to write
> shitty CMake that's very fragile and complex. I know some projects
> have replaced CMake with Meson for that reason.

I have no experience with CMake as yet, but will no doubt be required to
use it in the future - so I have a quick question for you.

In my makefiles for any non-trivial project, I find the source files by
wildcard searches, recursively through sub-directories. Basically, if a
..c or .cpp file exists somewhere in the project tree, it is part of the
project build. Can CMake do this with reasonable convenience, or would
I have to make a extra step with an external script?

Den 2024-01-17 skrev David Brown <david.brown@hesbynett.no>:
> On 17/01/2024 00:32, Andreas Kempe wrote:
>> Den 2024-01-16 skrev BGB <cr88192@gmail.com>:
>>> Things like CMake and Ninja seemed to work effectively in the past from
>>> what little I had used them...
>>>
>>
>> As a long time user of CMake, I think it works very well and I use it
>> for most of my projects, even if they're small. The most simple for I
>> use is usually
>>
>> cmake_minimum_required(VERSION $my_installed_version)
>> project($project_name)
>>
>> add_executable($output_binay $source_files)
>>
>> Replace the $-variables with actual values. I like it even for simple
>> things because it gives me make, make install and make clean or ninja
>> equivalents with three lines.
>>
>> That said, CMake is extremely flexible so it's very easy to write
>> shitty CMake that's very fragile and complex. I know some projects
>> have replaced CMake with Meson for that reason.
>
> I have no experience with CMake as yet, but will no doubt be required to
> use it in the future - so I have a quick question for you.
>
> In my makefiles for any non-trivial project, I find the source files by
> wildcard searches, recursively through sub-directories. Basically, if a
> .c or .cpp file exists somewhere in the project tree, it is part of the
> project build. Can CMake do this with reasonable convenience, or would
> I have to make a extra step with an external script?
>

CMake has support for it via globbing. You can for example do

file(GLOB_RECURSE SRCS "src/*.c")
add_executable(my_program ${SRCS})

file() searches recursively for all files ending in .c in the src
directory and puts them into the SRCS variable.

If you do this, I would suggest making sure to search from a
subdirectory in the top level CMake file, i.e. "subdir/*.c" instead of
"*.c", since if someone performs the build in a directory at the top
level, usually something like

cd my_project
mkdir build
cd build
cmake ..
make

it will cause CMake to recurse into the build directory and find
generated compiler test files.

On 17/01/2024 13:21, Andreas Kempe wrote:
> Den 2024-01-17 skrev David Brown <david.brown@hesbynett.no>:
>> On 17/01/2024 00:32, Andreas Kempe wrote:
>>> Den 2024-01-16 skrev BGB <cr88192@gmail.com>:
>>>> Things like CMake and Ninja seemed to work effectively in the past from
>>>> what little I had used them...
>>>>
>>>
>>> As a long time user of CMake, I think it works very well and I use it
>>> for most of my projects, even if they're small. The most simple for I
>>> use is usually
>>>
>>> cmake_minimum_required(VERSION $my_installed_version)
>>> project($project_name)
>>>
>>> add_executable($output_binay $source_files)
>>>
>>> Replace the $-variables with actual values. I like it even for simple
>>> things because it gives me make, make install and make clean or ninja
>>> equivalents with three lines.
>>>
>>> That said, CMake is extremely flexible so it's very easy to write
>>> shitty CMake that's very fragile and complex. I know some projects
>>> have replaced CMake with Meson for that reason.
>>
>> I have no experience with CMake as yet, but will no doubt be required to
>> use it in the future - so I have a quick question for you.
>>
>> In my makefiles for any non-trivial project, I find the source files by
>> wildcard searches, recursively through sub-directories. Basically, if a
>> .c or .cpp file exists somewhere in the project tree, it is part of the
>> project build. Can CMake do this with reasonable convenience, or would
>> I have to make a extra step with an external script?
>>
>
> CMake has support for it via globbing. You can for example do
>
> file(GLOB_RECURSE SRCS "src/*.c")
> add_executable(my_program ${SRCS})
>
> file() searches recursively for all files ending in .c in the src
> directory and puts them into the SRCS variable.
>
> If you do this, I would suggest making sure to search from a
> subdirectory in the top level CMake file, i.e. "subdir/*.c" instead of
> "*.c", since if someone performs the build in a directory at the top
> level, usually something like
>
> cd my_project
> mkdir build
> cd build
> cmake ..
> make
>
> it will cause CMake to recurse into the build directory and find
> generated compiler test files.

Thanks for that information - it looks like it will be convenient for
me. (And I do generally have various subdirectories - "src" for source
separate from "build" for builds, "docs", etc., according to the needs
of the project.)

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Tue, 16 Jan 2024 22:55:55 GMT, Scott Lurndal wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>>Why, can’t your groff installation generate PDF directly?
>>
>> It couldn't when I first wrote this rule a couple of decades ago.
>
>Here’s how I get a nicely typeset view of one of my own man pages:
>
> groff -ktman -Tpdf «troff-file» | okular - &

$ type okular
-ksh: whence: okular: not found

On Wed, 17 Jan 2024 00:45:54 +0000, Lawrence D'Oliveiro wrote:

> On Tue, 16 Jan 2024 22:55:55 GMT, Scott Lurndal wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>>Why, can’t your groff installation generate PDF directly?
>>
>> It couldn't when I first wrote this rule a couple of decades ago.
>
> Here’s how I get a nicely typeset view of one of my own man pages:
>
> groff -ktman -Tpdf «troff-file» | okular - &

man -t 3 mktemp >mktemp.ps

--
Lew Pitcher
"In Skills We Trust"

On Wed, 17 Jan 2024 16:07:54 +0000, Lew Pitcher wrote:

> On Wed, 17 Jan 2024 00:45:54 +0000, Lawrence D'Oliveiro wrote:
>
>> On Tue, 16 Jan 2024 22:55:55 GMT, Scott Lurndal wrote:
>>
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>
>>>>Why, can’t your groff installation generate PDF directly?
>>>
>>> It couldn't when I first wrote this rule a couple of decades ago.
>>
>> Here’s how I get a nicely typeset view of one of my own man pages:
>>
>> groff -ktman -Tpdf «troff-file» | okular - &
>
>
> man -t 3 mktemp >mktemp.ps

But you wanted a PDF, so
man -t 3 mktemp | ps2pdf - mktemp.pdf

--
Lew Pitcher
"In Skills We Trust"

On 2024-01-17, David Brown <david.brown@hesbynett.no> wrote:
> In my makefiles for any non-trivial project, I find the source files by
> wildcard searches, recursively through sub-directories. Basically, if a
> .c or .cpp file exists somewhere in the project tree, it is part of the
> project build. Can CMake do this with reasonable convenience, or would
> I have to make a extra step with an external script?

By the way, a useful idea, if you go that route, is to do that is with
git wildcard searches, like:

C_SRCS := $(shell git ls-files 'src/**/*.c')

so you are not picking up untracked local files into the build.
This means that a new file has to be git-added to be pulled in.

Of course, the practice assumes your project will be inseparable from
its git repository going forward. (Not unheard of nowadays, but
obviously a nonstarter for people who distribute tarball snapshots of
source.)

It's really better to assiduously list the files explicitly in the
Makefile. It's not like a daily chore, and can be done with the help
of wildcard searches for the initial population.

If I wanted wildcard-based population of OBJS, I'd put that into a
separate included makefile (that is checked into version control) and
have a "make objs" step.

When a new file is added, the developer has to run "make objs" to
reevaluate the wildcard search which will regenerate the "objs.mk" file.

If any stray files are pulled into "objs.mk" that shouldn't be,
that will be readily apparent in the diff. The file can list them
on separate lines like this, for easy diffing.

OBJS := \
src/parser.o \
src/lexer.o \
src/shouldnotbehere.o \
lib/buffer.o \
...

We can easily spot that src/shouldnotbehere.o should not be there
when reviewing the diff.

(Of course, OBJS is populated not by looking for .o files, but by
by looking for suffixes like .c, .cc and .S, which are then converted
to .o; the inference rules figure out the prerequisite source file
for each .o.)

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 17/01/2024 10:41, David Brown wrote:
> On 17/01/2024 00:32, Andreas Kempe wrote:
>> Den 2024-01-16 skrev BGB <cr88192@gmail.com>:
>>> Things like CMake and Ninja seemed to work effectively in the past from
>>> what little I had used them...
>>>
>>
>> As a long time user of CMake, I think it works very well and I use it
>> for most of my projects, even if they're small. The most simple for I
>> use is usually
>>
>>     cmake_minimum_required(VERSION $my_installed_version)
>>     project($project_name)
>>
>>     add_executable($output_binay $source_files)
>>
>> Replace the $-variables with actual values. I like it even for simple
>> things because it gives me make, make install and make clean or ninja
>> equivalents with three lines.
>>
>> That said, CMake is extremely flexible so it's very easy to write
>> shitty CMake that's very fragile and complex. I know some projects
>> have replaced CMake with Meson for that reason.
>
> I have no experience with CMake as yet, but will no doubt be required to
> use it in the future - so I have a quick question for you.
>
> In my makefiles for any non-trivial project, I find the source files by
> wildcard searches, recursively through sub-directories.  Basically, if a
> .c or .cpp file exists somewhere in the project tree, it is part of the
> project build.  Can CMake do this with reasonable convenience, or would
> I have to make a extra step with an external script?
>

I've recently become a fan of wildcard inputs like "*.c", at least for
programs that process multiple input files.

A compiler like gcc can be invoked using "gcc *.c", and now I can do the
same.

But on Windows, putting wildcards inside an @file then using 'gcc @file'
doesn't work; it will not expand those wildcard specs. (mcc @file will
work.)

I think this was specific to Windows, but I've just seen it fail on WSL too.

Does anyone know why this is?

It means that, where a project can be simply described by a sequence of
such filespecs, for example with this actual example:

*.c freetype/*.c samplerate/*.c

you can't have a lightweight makefile alternate by sticking them into an
@file. You need to enumerate every file, then maintain the file when the
list changes.

On Wed, 17 Jan 2024 16:03:41 GMT, Scott Lurndal wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>>Here’s how I get a nicely typeset view of one of my own man pages:
>>
>> groff -ktman -Tpdf «troff-file» | okular - &
>
> $ type okular
> -ksh: whence: okular: not found

ldo@theon:~> apt-cache search okular
okular-backend-odp - Okular backend for ODP documents
okular-backend-odt - Okular backend for ODT documents
libokular5core11 - libraries for the Okular document viewer
okular - universal document viewer
okular-dev - development files for the Okular libraries
okular-extra-backends - additional document format support for Okular
okular-mobile - mobile support for Okular
qml-module-org-kde-okular - mobile support for Okular - QML modules

It helps to try the right command ...

On 17/01/2024 19:11, Kaz Kylheku wrote:
> On 2024-01-17, David Brown <david.brown@hesbynett.no> wrote:
>> In my makefiles for any non-trivial project, I find the source files by
>> wildcard searches, recursively through sub-directories. Basically, if a
>> .c or .cpp file exists somewhere in the project tree, it is part of the
>> project build. Can CMake do this with reasonable convenience, or would
>> I have to make a extra step with an external script?
>
> By the way, a useful idea, if you go that route, is to do that is with
> git wildcard searches, like:
>
> C_SRCS := $(shell git ls-files 'src/**/*.c')
>
> so you are not picking up untracked local files into the build.
> This means that a new file has to be git-added to be pulled in.
>

That's certainly a possibility, and could be a useful hint for some
people. But I am strict about all project source files, and nothing but
project source files, being in the src directory.

> Of course, the practice assumes your project will be inseparable from
> its git repository going forward. (Not unheard of nowadays, but
> obviously a nonstarter for people who distribute tarball snapshots of
> source.)
>
> It's really better to assiduously list the files explicitly in the
> Makefile. It's not like a daily chore, and can be done with the help
> of wildcard searches for the initial population.
>

I prefer not to, but I realise that's a matter of preference.

> If I wanted wildcard-based population of OBJS, I'd put that into a
> separate included makefile (that is checked into version control) and
> have a "make objs" step.
>

I make my "objs" from my "srcs" :

objfiles_src := $(cfiles:.c=.o) $(cppfiles:.cpp=.o)
objfiles := $(addprefix $(obj_dir),$(patsubst ../%,%,$(objfiles_src)))

> When a new file is added, the developer has to run "make objs" to
> reevaluate the wildcard search which will regenerate the "objs.mk" file.

It can certainly be done that way. I find the automatic generation is
fast enough that there is little benefit in doing it manually. But it
could be a different matter in a very big project.

>
> If any stray files are pulled into "objs.mk" that shouldn't be,
> that will be readily apparent in the diff. The file can list them
> on separate lines like this, for easy diffing.
>
> OBJS := \
> src/parser.o \
> src/lexer.o \
> src/shouldnotbehere.o \
> lib/buffer.o \
> ...
>
> We can easily spot that src/shouldnotbehere.o should not be there
> when reviewing the diff.
>
> (Of course, OBJS is populated not by looking for .o files, but by
> by looking for suffixes like .c, .cc and .S, which are then converted
> to .o; the inference rules figure out the prerequisite source file
> for each .o.)
>

Yes.

There are many possibilities here.

Kaz Kylheku <433-929-6894@kylheku.com> writes:
> On 2024-01-17, David Brown <david.brown@hesbynett.no> wrote:
>> In my makefiles for any non-trivial project, I find the source files by
>> wildcard searches, recursively through sub-directories. Basically, if a
>> .c or .cpp file exists somewhere in the project tree, it is part of the
>> project build. Can CMake do this with reasonable convenience, or would
>> I have to make a extra step with an external script?
>
> By the way, a useful idea, if you go that route, is to do that is with
> git wildcard searches, like:
>
> C_SRCS := $(shell git ls-files 'src/**/*.c')
>
> so you are not picking up untracked local files into the build.
> This means that a new file has to be git-added to be pulled in.

I haven't verified this in the documentation, but git wildcards appear
to be recursive (unlike most shell wildcards), so the above could be:

C_SRCS := $(shell git ls-files 'src/*.c')

(Which raises the question of how `git ls-files` can be told to list
only *.c files directly under the src directory. I don't know the
answer.)

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Wed, 17 Jan 2024 16:03:41 GMT, Scott Lurndal wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>>Here’s how I get a nicely typeset view of one of my own man pages:
>>>
>>> groff -ktman -Tpdf «troff-file» | okular - &
>>
>> $ type okular
>> -ksh: whence: okular: not found
>
> ldo@theon:~> apt-cache search okular
> okular-backend-odp - Okular backend for ODP documents
> okular-backend-odt - Okular backend for ODT documents
> libokular5core11 - libraries for the Okular document viewer
> okular - universal document viewer
> okular-dev - development files for the Okular libraries
> okular-extra-backends - additional document format support for Okular
> okular-mobile - mobile support for Okular
> qml-module-org-kde-okular - mobile support for Okular - QML modules
>
>It helps to try the right command ...

My Fedora install doesn't support apt-cache, apt or dpkg commands.

I'm perfectly aware that one can download pretty much any package
for any distribution, however:

xpdf is the best linux pdf viewer, in my opinion. I detest acroread, evince and similar ilk.

On 2024-01-17, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>> On 2024-01-17, David Brown <david.brown@hesbynett.no> wrote:
>>> In my makefiles for any non-trivial project, I find the source files by
>>> wildcard searches, recursively through sub-directories. Basically, if a
>>> .c or .cpp file exists somewhere in the project tree, it is part of the
>>> project build. Can CMake do this with reasonable convenience, or would
>>> I have to make a extra step with an external script?
>>
>> By the way, a useful idea, if you go that route, is to do that is with
>> git wildcard searches, like:
>>
>> C_SRCS := $(shell git ls-files 'src/**/*.c')
>>
>> so you are not picking up untracked local files into the build.
>> This means that a new file has to be git-added to be pulled in.
>
> I haven't verified this in the documentation, but git wildcards appear
> to be recursive (unlike most shell wildcards), so the above could be:
>
> C_SRCS := $(shell git ls-files 'src/*.c')

You are right; we don't need the double star glob in git ls-files,
(and it appears not to work, so we cannot use it)./

The ls-files man page doesn't document it the format.

For --exclude patterns, it says that they are gitignore patterns
and for that, there is detailed documentation. gitignore supports
double star patterns fro matching zero or more directory components.

So it looks as if ls-files doesn't use the same patterns as gitignore.

The behavior is similar to what would be obtained if we applied the
POSIX fnmatch function to each element of a list of the paths in the
git index, and omitted the FNM_PATHNAME bit which prevents * and ? from
matching across the / separators.

The shell does this kind of matching in some non-path contexts:

$ case a/b.c in *.c ) echo yes ;; esac
yes

For gitignore, the implemented glob-like matching, with the double
star extension (not in POSIX).

> (Which raises the question of how `git ls-files` can be told to list
> only *.c files directly under the src directory. I don't know the
> answer.)

Unfortunately, the answer seems to be to remove quotes to make the shell
do the expanding, so that git then receives the list of names to list
(possibly too large for the argument limit, needing xargs).

If any of the names refer to untracked files, those will be omitted,
so it will work out.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On Wed, 17 Jan 2024 18:11:55 -0000 (UTC), Kaz Kylheku wrote:

> It's really better to assiduously list the files explicitly in the
> Makefile.

I think I agree. And furthermore, you only want to list them once, not
in multiple places.

And how about writing CMake script to generate the list of names in
the form of C code? Some years ago I submitted a patch to the Blender
build process <https://developer.blender.org/T37228> to simplify the
management of the list of files for their “DNA” data-interface system.
They weren’t keen on it.

On Wed, 17 Jan 2024 22:08:25 GMT, Scott Lurndal wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> ldo@theon:~> apt-cache search okular
>> okular-backend-odp - Okular backend for ODP documents
>> okular-backend-odt - Okular backend for ODT documents
>> libokular5core11 - libraries for the Okular document viewer
>> okular - universal document viewer
>> okular-dev - development files for the Okular libraries
>> okular-extra-backends - additional document format support for Okular
>> okular-mobile - mobile support for Okular
>> qml-module-org-kde-okular - mobile support for Okular - QML modules
>
> My Fedora install doesn't support apt-cache, apt or dpkg commands.

Don’t you know what their equivalents are?

Kaz Kylheku <433-929-6894@kylheku.com> writes:
> On 2024-01-17, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>> On 2024-01-17, David Brown <david.brown@hesbynett.no> wrote:
>>>> In my makefiles for any non-trivial project, I find the source files by
>>>> wildcard searches, recursively through sub-directories. Basically, if a
>>>> .c or .cpp file exists somewhere in the project tree, it is part of the
>>>> project build. Can CMake do this with reasonable convenience, or would
>>>> I have to make a extra step with an external script?
>>>
>>> By the way, a useful idea, if you go that route, is to do that is with
>>> git wildcard searches, like:
>>>
>>> C_SRCS := $(shell git ls-files 'src/**/*.c')
>>>
>>> so you are not picking up untracked local files into the build.
>>> This means that a new file has to be git-added to be pulled in.
>>
>> I haven't verified this in the documentation, but git wildcards appear
>> to be recursive (unlike most shell wildcards), so the above could be:
>>
>> C_SRCS := $(shell git ls-files 'src/*.c')
>
> You are right; we don't need the double star glob in git ls-files,
> (and it appears not to work, so we cannot use it)./
>
> The ls-files man page doesn't document it the format.

This is odd. As far as I can tell, git's behavior (as of 2.43.0)
doesn't match either its documentation or the behavior of '**' wildcards
in bash with "globstar" enabled.

I suggest this isn't the place to discuss the details.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Wed, 17 Jan 2024 22:08:25 GMT, Scott Lurndal wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>> ldo@theon:~> apt-cache search okular
>>> okular-backend-odp - Okular backend for ODP documents
>>> okular-backend-odt - Okular backend for ODT documents
>>> libokular5core11 - libraries for the Okular document viewer
>>> okular - universal document viewer
>>> okular-dev - development files for the Okular libraries
>>> okular-extra-backends - additional document format support for Okular
>>> okular-mobile - mobile support for Okular
>>> qml-module-org-kde-okular - mobile support for Okular - QML modules
>>
>> My Fedora install doesn't support apt-cache, apt or dpkg commands.
>
>Don’t you know what their equivalents are?

Of course. rpm and/or yum. I'm not interested in changing PDF readers, however.

Ah, a google search shows that Okular is like evince and acroread. No thanks.