Re: [Cron-bug] Build environment

[Jeff Bailey]

On Sun, Oct 21, 2001 at 03:51:48PM -0400, Ryan M. Golbeck wrote:

> > I have checked in the build environment as we discussed on IRC.  I
> > have also made a small patch to your cron-specs.texi so that it
> > names the file correctly.

> What is src/cronttab for?

Err. typo - it shouldn't exist.

> > Lastly, I have started the ChangeLog and think that we should keep
> > it up to date.  I generally like an entry in the ChangeLog for
> > just about everything, but your call.

> Agreed.  Wasn't sure if there should be a separate one in doc/ or
> not though.  Since noting changes to documentation isn't as useful
> to users.

I disagree.  While it's not useful initally to users, If someone sees
"Rewrote section x", or "correct misinformation in section x", it
might be a signal.

> We should probably start with deciding what needs to go in libcron to
> make sure we don't code redundant functions into each of the commands.

I generally work on the idea that libcron is the place where
refactoring happens.  So, if we realize that something's been
implemented in both at and cronttab, for instance, we would just
migrate it as we saw fit.

I don't tend to plan too much in advance of coding.  I find that it
tends to make me not program when I have the urge, so stuff that
would've been done slower (due to poor design) doesn't get done at
all.

> So, basically we follow the GNU library standard for coding it?
> Exported functions are one per file, with static functions in that
> file if need be.  And we have have the private functions in other
> files?  Tell me more about your one function per file deal. :)

I like one function per file, because I don't have to generate tags
lists.  When I'm looking for "add_entry()", I can expect to find it in
"add_entry.c"

I very rarely have static functions.  Most of the time, anything I
would find worth seperating out, I would use in more than one place.

Tks,
jeff Bailey

-- 
Abandon the search for truth; settle for a good fantasy.