[Nut-upsdev] [Nut-upsuser] Belkin F6C1100-UNV

[Peter Selinger]

Arjen de Korte wrote:
> 
> Another thing to note is that in my opinion, the SVN version number need
> not be updated for everything that is submitted. If the dependencies for a
> given tool don't require that it is rebuild (because the sources are not
> touched by an update), I would even prefer that the SVN revision number
> for that particular executable doesn't change.

I spent more time thinking about this today, and I am still not sure
of the best way to do this. Here is why I think it's complicated:

(1) one option is to let make create/update a *.h file and let all
  sources that display the version number include it. Problem: each
  time you do "svn update", all targets have to be recompiled, even
  the ones that did not change (i.e. whose only change was the version
  number itself). This means a lot of unnecessary compiling, somewhat
  reversing the benefits of dependency checking. 

(2) the second option is to let make create/update a *.c file that
  either exports a function (as in Eric's patch) or a static string.
  In this case, when you do "svn update", only once source has to be
  recompiled, but all targets still have to be re-linked. This is
  faster than (1), but re-linking everything in driver/* still takes a
  long time.

(3) the third option is to add a -D option to CFLAGS dynamically in the
  relevant Makefile.am's. Since CFLAGS is not considered a dependency,
  recompiled sources would get the updated revision number, but stuff
  does not have to be re-compiled or re-linked just because the
  revision number changed. 

  The disadvantage of this is: most targets are obtained by linking
  several object files together, for example usbhid-ups.o libhid.o
  libusb.o hidparser.o apc-hid.o belkin-hid.o explore-hid.o mge-hid.o
  tripplite-hid.o ../common/libcommon.a ../common/upsconf.o
  ../common/parseconf.o ../common/state.o main.o dstate.o. Only one or
  two of these display the SVN revision. So if a lot of these files
  change, but the one that contains the SVN revision string does not,
  then you'll still get the old version number. 

It seems that all three methods have significant disadvantages.
The question is: which disadvantage is easiest to tolerate? Your input
is needed here.

I would like to point out that the challenges this presents are
specific to NUT, because NUT provides such a large collection of
executable files. Most other projects provide a single monolithic
application. If one is compiling an application, option (2) work best,
because at most one file has to be recompiled and at most one target
has to be re-linked. If the version number is only displayed in one or
a few places, option (1) also works well for monolithic projects.

-- Peter