[Toybox] Put syslogd and logger into the same file?

[Felix Janda]

Rob Landley wrote:
> On 08/18/2013 11:55:22 AM, Felix Janda wrote:
> > Rob Landley wrote:
> > > On 08/10/2013 04:22:58 PM, Felix Janda wrote:
> > > > Right now syslogd.c contains code from <sys/syslog.h> declaring  
> > the
> > > > arrays
> > > > prioritynames and facilitynames, which map human readable strings  
> > to
> > > > numerical ids. logger.c contains very similar array definitions.
> > > >
> > > > <sys/syslog.h> declares these arrays only when SYSLOG_NAMES has  
> > been
> > > > #defined. The structure with the descriptive name "CODE" used for  
> > the
> > > > array members is also only defined conditionally. Something like
> > > >
> > > > #ifndef SYSLOG_NAMES
> > > > extern CODE prioritynames[];
> > > > extern CODE facilitynames[];
> > > > #endif
> > > >
> > > > is also missing in <sys/syslog.h>.
> > > >
> > > > IMO the least bad way to use the arrays from <sys/syslog.h> would  
> > be
> > > > to
> > > > combine syslogd.c and logger.c into one file and there define
> > > > SYSLOG_NAMES before including toys.h.
> > >
> > > It's a good idea, but:
> > >
> > > What I haven't figured out yet is how to do the argument parsing.
> > > syslogd and logger have very different option strings.
> > >
> > > Right now there's only one GLOBALS block per file. That's easy  
> > enough
> > > to fix, and we can #undef TT and #define TT toys. But the FLAG_*  
> > macros
> > > are also defined based on FOR_command. And that's harder to clean  
> > up...
> > 
> > I was aware that there might be some problems with the build  
> > architecture
> > but couldn't name them. Thanks for the clarification.
> > 
> > I have no idea how to get two commands with overlapping conflicting  
> > options
> > to work when put into the same file.
> 
> Neither do I, which is the problem. :)

The problem could also be the abuse of the build infrastructure.

> In theory I could do a second #include to get different FLAG macros,  
> but it would have to #undefine all the current flag macros first, which  
> means I'd have to tell it which version I was switching _from_, so it'd  
> look something like:
> 
>    #define FROM_command
>    #define FOR_command
>    #include "generated/switchflags.h"
> 
> As with the OPTSTR_name stuff for oldtoy, the complexity of the  
> infrastructure to implement this (and resulting large and ugly  
> generated/blah.h) makes the mechanism less attractive even if using in  
> commands can then be very simple. I don't like having the common  
> infrastructure be incomprehensible black magic even if it "just works"  
> when you use it.
> 
> Tradeoffs. Lots and lots of tradeoffs. I still might do it, but I have  
> to get comfortable with the idea of adding more crap to generated/*.h...

I don't want a much more complex infrastructure just because of this
minor problem.

> > So how about the following hack?
> > 
> > Keep them in separate files. Have one common config symbol,
> 
> Which implies one common .c file because the top level config symbols  
> determine which toys/*/*.c files get fed to the gcc command line.
> 
> Ok, that's no longer ENTIRELY true. It used to be that the config  
> symbol CP would include cp.c but CP_MORE wouldn't becuase ther was an  
> underscore in it. Then I needed to support stuff like switch_root and  
> nbd-client which have underscores in their config symbols (- gets  
> squashed to _ and then everything is uppercased), so now what it does  
> is checks each config symbol to see if their _is_ a corresponding .c  
> file and assembles a gcc command line from the ones that match.
> 
>    http://landley.net/hg/toybox/rev/654
> 
> So it'll work, but it's confusing. (I normally try to put common code  
> in lib, or not have it.)

I decided that it's better (and it even makes sense) to have logger
depend on syslogd. See the code in my other mail.

> > tear everything
> > out of logger.c but logger_main, declare SYSLOG_NAMES in syslogd.c,  
> > put
> > something like the current lookup() in logger.c to syslogd.c and make  
> > an
> > extern declaration in logger.c. The new lookup() (better use a less  
> > generic
> > name then) should accept an integer as its first argument instead of  
> > the
> > table, say 0 stands for facilities and 1 for priorities.
> 
> I've read that twice and am not following it, which is not a good sign.
>
> Alas, "how to be simple" is not, itself, always simple.

The patch in my other mail should make clear what I meant.

> Could you poke me about this again next week? I want to try to clear  
> some of the other pending stuff of my plate. (Todo stack too deep.)

I'll do that.

Felix

 1377020833.0