Yo Hal!

On Fri, 14 Mar 2025 13:58:36 -0700
Hal Murray via devel <devel@ntpsec.org> wrote:

> Gary said (in a gitlab discussion):
> > We need to get rid of most #ifdef.  Newer languages don't support
> > it, and it leads to binaries that behave differently.  DEBUG should
> > be the first to go.   
> 
> How do they configure things?

That question covers a lot of ground, but somehow modern languages
mange to do it.

Three major things that ifdef historically deals with:

1. working around language features that vary over time.

   Be like Rust that just says: "use this version of the compiler".

   Be like Python, throw exceptions on unknown or removed features
   and let the program try to reciver.

   I see no way around #ifdef for programs that need to use C and
   run on multiple OS.

2. Conditionally buiding features, like debug, individual
   drivers.

   Nowdays, sine binary size is rarely an issue, just build in eberything.

3. Configuring options at compile time like patch, usernames, etc.

   Those can all be done via command line options or runtime config files.

> I expect the environment is new enough that most code can run on, for
> example, Linux, Windows, and FreeBSD.  But we are often dealing with
> rough edges.  Consider drop root.

Yes, my case 1 above.  If we stick with C, thenn we are stuck with that
part.  But things like debug should always be built in.  Things like
username, niceness, etc. should be runtime configurable.

Thus my complaint about #ifdef DEBUG.  I hate to have to rebuild to
turn on debug!  And hard to get users to rebuild when all they did was
install a package.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        g...@rellim.com  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
_______________________________________________
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel

Reply via email to