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

[Arjen de Korte]

>> 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 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.

Best regards, Arjen