[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.
> 
> I'll take that back, see below.
> 
> >> 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.
> 
> Indeed.
> 
> > (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.
> 
> I'm afraid this is probably the best solution, since I realized the
> dependencies sometimes don't end with what is needed for compilation and
> linking of a binary. For instance, the files for hotplug/udev are not a
> dependency for any driver, yet we still want to see which version they
> are. The same goes for several other files. So after all it may be best to
> just update the SVN revision identification of every binary if something
> is updated, since this is the only way to display the version for some
> files.
> 
> Personally, I'm not that worried about the time it takes to relink
> everything. Actually, at present I usually compile the lot (even sources
> that were not touched), just to rule out any mishaps if we somehow missed
> a dependency here or there.
>  
> > (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.
> 
> Even worse than option 2. We would miss a lot of changes in the version
> numbers. I don't think this is worth the effort, this is not much better
> than what we have now.
> 
> > It seems that all three methods have significant disadvantages.
> > The question is: which disadvantage is easiest to tolerate? Your input
> > is needed here.
> 
> I think the best option is to
> 
>     #define UPS_VERSION (upsversion())
> 
> and add the *.c file where we define that function to the list of
> dependencies for all binaries. In contrast to Eric's original patch,
> changing lots of sources is probably not needed (nor desireable) if we use
> a macro. We could then generate the *.c file through autoconf and let it
> return a statically allocated string. Rather than in this function, the
> magic that determines what to return (NUT version with or without SVN
> revision number) should be done at build time, not runtime.

I agree that (2) is the best solution, with some additional
simplifications: a separate .c file is not needed, as we can use
common.c (which is already linked to everything using
UPS_VERSION). Also, the level of indirection of a function returning a
fixed string is unnecessary; we can just export the string itself.

I have modified Eric's patch accordingly and committed another
changeset (r927); please test and feedback. I also used some tricks
from GnuCash, another open source project that has solved the same
problem. 

The changeset primarily applies to configure.in and several
Makefile.am, plus a modification in common.[ch].

I added "FORCE" in strategic places in several Makefile.am. This is
technically unnecessary if all the user is doing is "make all" at top
level. However, these are necessary if the user builds only a
specified target in a subdirectory.
 
> > 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.
> 
> Another option might be to add additional version strings for the
> binaries, that can be changed manually if something relevant to that
> specific binary was changed (like many drivers already have). The lack of
> automation probably means that this is prone to errors/forgetting to
> update the binary version number however.

Yes, it doesn't work so well even in the cases where we are already
doing it. Hopefully it will be unnecessary now. 

-- Peter