Mods configuration

23 views
Skip to first unread message

Jay Lash

unread,
Nov 30, 2011, 1:33:56 PM11/30/11
to Backwoods Logger development discussion
Here is a config.h that I have set up as a starting point for
discussion:


/*
* Steves standard copyright notice removed for brevity
*/
#ifndef _CONFIG_H_
#define _CONFIG_H_

/
*-----------------------------------------------------------------------
*/
// This file serves as a place to enable/disable various
functionality.
//
// The suggested naming convention for constants is:
// <developer initials>_<functionality name>_MOD
//
// Where the developer initials really just serve as a namespace.
/
*-----------------------------------------------------------------------
*/

/
*************************************************************************/
// Show current-data values as the lock screen instead of the BWLogger
logo
#define JJL_LOCKSCREEN_MOD
#define LOCKSCREEN_MODE 1
/
*************************************************************************/
// Record daily high/low values for temp/pressure/altitude, make them
// available on the main screen via the line selection menu
#define JJL_DAILYHIGHLOW_MOD
/
*************************************************************************/
// Add a couple of getter functions for accessing clock data
#define JJL_CLOCKACCESS_MOD


/
*-----------------------------------------------------------------------
*/
// Additional option configuration can be done in this section, i.e.
// if there are dependencies between options, this is where you can
test
// to make sure everything is enabled that needs to be enabled.
/
*-----------------------------------------------------------------------
*/

/
*************************************************************************/
// If the lock screen mod is enabled but the mode is not defined,
define the mode
#ifdef JJL_LOCKSCREEN_MOD
# ifndef LOCKSCREEN_MODE
# define LOCKSCREEN_MODE 0
# endif
#endif

/
*************************************************************************/
// If the DailyHighLow mod is enabled but the Clock mod is not, enable
it
// The high/low mod uses clock access functions to detect the new day
// and reset the high/low values
#ifdef JJL_DAILYHIGHLOW_MOD
# ifndef JJL_CLOCKACCESS_MOD
# define JJL_CLOCKACCESS_MOD
# endif
#endif


#endif /* _CONFIG_H_ */

Steve Chamberlin

unread,
Nov 30, 2011, 3:10:02 PM11/30/11
to backwoods-lo...@googlegroups.com
Hi Jay,

//
// The suggested naming convention for constants is:
//      <developer initials>_<functionality name>_MOD

I don't think it's necessary to prefix symbols with your initials-- in fact I'd prefer that you don't. I once worked in codebase full of drhDoSomething() functions passing SLL_CONSTANT values to bhoMethod(), and it was a mess. :-) 

I'd suggest just a single symbol with a name that describes what it does, set to 1 to enable an option or 0 to disable it. Something like:

/* Lock screen data display
   Jay Lash, j...@somewhere.com
   Shows current data values on the lock screen, instead of the BWLogger logo
*/
#define LOCKSCREEN_DATA_DISPLAY 0

Most changes should be able to turned on and off with a single symbol. I wouldn't worry yet about dependencies between changes until a real-world example arises. If your daily high/low changes also require some new clock access functions, then make the clock access functions enabled by the same symbol. Or if the clock access functions are generally useful, just add them to the main body of code, without any #if check for conditional compilation. 

To your source control question, I've never worked on another open source project either, but I have worked in some large commercial code bases with dozens of developers. In this case, I think it will work fine for people to add changes straight to the main branch of the code, surrounded by a #if test where necessary. If that eventually becomes unworkable or creates conflicts, then we can explore a more formal mechanism for registering and installing mods. For now, though, I'd prefer to keep it simple.

I also want to point out that not all changes will be mods. Some will be straight changes or improvements to the main code. For example, if Derek makes the measurement resolution changes that were discussed yesterday, that would probably be a plain change, rather than an optional mod, since it's better all-around.

And some related discussion - when is it appropriate to check in
changes to the main code base?

Whenever you're ready. I'd appreciate seeing a diff of any changes first, or just the modified files if that's easier, so I can make sure people aren't submitting crazy stuff. Then I'll add you as a submitter to the Google Code project, and you can submit the changes to SVN.

Steve

Derek Kozel

unread,
Dec 1, 2011, 1:14:05 AM12/1/11
to backwoods-lo...@googlegroups.com
I'm certainly hoping to make the changes, but don't know if I'll have the time before my trip especially as I don't actually have a logger at this point.

Jay Lash

unread,
Dec 1, 2011, 9:36:32 AM12/1/11
to Backwoods Logger development discussion
Thanks Steve. Most of that all works for me. But I would like some
other folks thoughts on the convention for the enable symbol. I
proposed a symbol

#define SOME_MOD

which would use a test like

#ifdef SOME_MOD or #if defined(SOME_MOD)

And you proposed a symbol

#define SOME_MOD 1

which would use a test like

#if (1 == SOME_MOD)


I think for an enable/disable, the intent is more clear with a "is it
defined or not". To me, checking for a specific value implies that
the value is what matters and is more prone to errors. What happens
if the definition gets changed to

#define SOME_MOD 2
or
#define SOME_MOD


In your convention both cases would disable the mod while in mine
neither would.


Yes, we are all developers and this type of project is not likely to
get many "newbies". Yes, there will undoubtedly be a comment that
explains the convention being used. I guess part of it is my
personal style and what Im used to but part of it is what I see as
less error prone and easier to maintain.

Other folks have any thoughts on the subject?

On Nov 30, 2:10 pm, Steve Chamberlin <steve.chamber...@gmail.com>
wrote:

Steve Chamberlin

unread,
Dec 1, 2011, 10:11:39 AM12/1/11
to backwoods-lo...@googlegroups.com
Of course-- I didn't mean to sign you up for a deadline or anything! :-)

If you want a prebuilt Logger, I still have more Logger Minis for $59.

Steve

Steve Chamberlin

unread,
Dec 1, 2011, 2:32:03 PM12/1/11
to backwoods-lo...@googlegroups.com
Hi guys,

I'm OK with just defining the symbol instead of giving it a value of 0 or 1, although the 0/1 usage is the norm in most projects I've seen. I did a quick Google search for "config.h", and the first three examples all use the 0/1 pattern:


The test only needs

#if SOME_MOD

rather than

#if (1 == SOME_MOD)

since you just want to test that SOME_MOD has a non-zero value.

Do whatever makes the most sense to you with the #define-- it's a minor point as far as I'm concerned.

Looking forward to seeing your changes! :-)

Steve

Jay Lash

unread,
Dec 3, 2011, 9:21:48 AM12/3/11
to Backwoods Logger development discussion
It is a minor point for me also. As there is some precedent, I went
ahead and used the 0/1 method.

I just sent you the files for review. They contain modifications for:

* Showing current data on the lock screen instead of the BWLogger logo

* Track daily high/low values for temp/altitude/pressure. Add them to
the list of items that can be displayed on the Current Data screen.
They are also available to show on the lock screen.

* Add a couple of functions to access date and time. Used by the
daily high/low mod but could be of general use.


I am really enjoying this; it has been way too long since I got to
work on a small platform.

Jay

On Dec 1, 1:32 pm, Steve Chamberlin <steve.chamber...@gmail.com>
wrote:


> Hi guys,
>
> I'm OK with just defining the symbol instead of giving it a value of 0 or 1, although the 0/1 usage is the norm in most projects I've seen. I did a quick Google search for "config.h", and the first three examples all use the 0/1 pattern:
>

> http://www.opensource.apple.com/source/WebCore/WebCore-106/config.hhttp://www.mbsks.franken.de/sosse/html/config_8h-source.htmlhttp://134.173.34.196/ctan/support/bmeps/config.h

Reply all
Reply to author
Forward
0 new messages