Groups | Search | Server Info | Login | Register
Groups > comp.arch.embedded > #32400
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: 32 bits time_t and Y2038 issue |
| Date | 2025-03-22 15:57 +0000 |
| Organization | To protect and to server |
| Message-ID | <vrmmls$2nts5$1@paganini.bofh.team> (permalink) |
| References | (4 earlier) <vrbi79$2a30t$1@dont-email.me> <slrnvtjeq9.566.news-1513678000@a-tuin.ms.intern> <vrcidh$35fbp$2@dont-email.me> <vrjrm9$2ehre$1@paganini.bofh.team> <vrk1i7$1qjnk$1@dont-email.me> |
David Brown <david.brown@hesbynett.no> wrote:
> On 21/03/2025 15:04, Waldek Hebisch wrote:
>> David Brown <david.brown@hesbynett.no> wrote:
>>> On 18/03/2025 19:28, Michael Schwingen wrote:
>>>> On 2025-03-18, David Brown <david.brown@hesbynett.no> wrote:
>>>
>>>>> A good makefile picks up the new files automatically and handles all the
>>>>> dependencies, so often all you need is a new "make -j".
>>>>
>>>> I don't do that anymore - wildcards in makefiles can lead to all kinds of
>>>> strange behaviour due to files that are left/placed somewhere but are not
>>>> really needed.
>>>
>>> I'm sure you can guess the correct way to handle that - don't leave
>>> files in the wrong places :-)
>>>
>>>> I prefer to list the files I want compiled - it is not that
>>>> much work.
>>>>
>>>
>>> In a project of over 500 files in 70 directories, it's a lot more work
>>> than using wildcards and not keeping old unneeded files mixed in with
>>> source files.
>>
>> In project with about 550 normal source files, 80 headers, 200 test
>> files, about 1200 generated files spread over 12 directories I use
>> explicit file lists. Lists of files increase volume of Makefile-s,
>> but in my experience extra work to maintain file list is very small.
>> Compared to effort needed to create a file, adding entry to file list
>> is negligible.
>
> That's true.
>
> But compared to have a wildcard search to include all .c and .cpp files
> in the source directories, maintaining file lists is still more than
> nothing!
>
> However, the real benefit from using automatic file searches like this
> is two-fold. One is that you can't get it wrong - you can't forget to
> add the new file to the list, or remove deleted or renamed files from
> the list.
Depends on your workflow. I frequently do developement outside
of source tree, then one can forget to copy file to the source
tree. Explicit list means that you get clear build error when file
is missing, that needs fixing anyway. Possibly less clear
error when you add file without updating file list, but since
normally adding a file is followed by make it is easy to find
the reason.
> The other - bigger - effect is that there is never any doubt
> about the files in the project. A file is in the project and build if
> and only if it is in one of the source directories.
A file is in the project if and only if it is in the source
repository. Concerning "build", project normally allows
optional/variant files and file is build if and only if it
is needed in choosen configuration. Clearly, file not needed
in any configuration has no place in source repository.
During developement in my work tree (different from source
repository!) there may be some auxiliary file (it is rather
infrequent and not a big deal anyway, I just mention how
I work).
> That consistency is
> very important to me - and to anyone else trying to look at the project.
> So any technical help in enforcing that is a good thing in my book.
Well, for me (as mentioned above) "files in the project" and "build files"
are different things.
>> Explicit lists are useful if groups of files should get somewhat
>> different treatment (I have less need for this now, but it was
>> important in the past).
>>
>
> I do sometimes have explicit lists for /directories/ - but not for
> files. I often have one branch in the source directory for my own code,
> and one branch for things like vendor SDKs and third-party code. I can
> then use stricter static warnings for my own code, without triggering
> lots of warnings in external code.
>
>> IMO being explicit helps with readablity and make code more
>> amenable to audit.
>>
>
> A simple rule of "all files are in the project" is more amenable to audit.
Maybe your wildcard use is very simple, but year ago wildcards
were important part in obfuscationg presence of maliciuous code
in lzma.
But more important part is keeping info together, inside Makefile.
--
Waldek Hebisch
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar
32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-11 16:22 +0100
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-11 17:32 +0100
Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-11 23:21 +0100
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-12 10:33 +0100
Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-12 16:48 +0100
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-12 17:39 +0100
Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-12 18:13 +0100
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-12 19:18 +0100
Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-13 09:57 +0100
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-13 16:51 +0100
Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-14 13:27 +0100
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-14 14:20 +0100
Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-12 08:44 +0100
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-12 11:14 +0100
Re: 32 bits time_t and Y2038 issue antispam@fricas.org (Waldek Hebisch) - 2025-03-14 01:48 +0000
Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-14 08:36 +0100
Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-15 16:30 +0000
Re: 32 bits time_t and Y2038 issue Grant Edwards <invalid@invalid.invalid> - 2025-03-15 17:02 +0000
Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-15 23:26 +0000
Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-18 09:21 +0100
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-18 11:34 +0100
Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-18 17:31 +0100
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-18 20:29 +0100
Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-21 09:20 +0000
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-21 13:54 +0100
Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-21 20:53 +0000
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-22 11:19 +0100
Re: 32 bits time_t and Y2038 issue antispam@fricas.org (Waldek Hebisch) - 2025-03-21 14:35 +0000
Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-18 18:28 +0000
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-18 20:43 +0100
Re: 32 bits time_t and Y2038 issue Grant Edwards <invalid@invalid.invalid> - 2025-03-18 20:58 +0000
Re: 32 bits time_t and Y2038 issue Hans-Bernhard Bröker <HBBroeker@gmail.com> - 2025-03-18 23:31 +0100
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-19 11:24 +0100
Re: 32 bits time_t and Y2038 issue Grant Edwards <invalid@invalid.invalid> - 2025-03-19 14:27 +0000
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-19 17:33 +0100
Re: 32 bits time_t and Y2038 issue Grant Edwards <invalid@invalid.invalid> - 2025-03-19 19:08 +0000
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-19 21:14 +0100
Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-21 09:48 +0000
Re: 32 bits time_t and Y2038 issue Grant Edwards <invalid@invalid.invalid> - 2025-03-21 13:27 +0000
Re: 32 bits time_t and Y2038 issue antispam@fricas.org (Waldek Hebisch) - 2025-03-19 22:09 +0000
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-20 09:26 +0100
Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-21 22:40 +0100
Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-21 09:23 +0000
Re: 32 bits time_t and Y2038 issue Hans-Bernhard Bröker <HBBroeker@gmail.com> - 2025-03-21 22:38 +0100
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-19 08:24 +0100
Re: 32 bits time_t and Y2038 issue antispam@fricas.org (Waldek Hebisch) - 2025-03-21 14:04 +0000
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-21 16:45 +0100
Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-21 22:51 +0100
Re: 32 bits time_t and Y2038 issue Hans-Bernhard Bröker <HBBroeker@gmail.com> - 2025-03-22 00:00 +0100
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-22 14:29 +0100
Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-22 14:46 +0000
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-22 17:57 +0100
Re: 32 bits time_t and Y2038 issue antispam@fricas.org (Waldek Hebisch) - 2025-03-22 15:57 +0000
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-22 18:02 +0100
Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-18 18:44 +0000
csiph-web