Add build information to libavrdude and avrdude and display it #1698
Conversation
|
Interestingly, the msvc x64 build fails when compiling |
src/libavrdude.h
Outdated
| @@ -1522,8 +1526,8 @@ void terminal_setup_update_progress(); | |||
| extern "C" { | |||
| #endif | |||
|
|
|||
| void win_sys_config_set(char sys_config[PATH_MAX]); | |||
| void win_usr_config_set(char usr_config[PATH_MAX]); | |||
| void win_sys_config_set(char *sys_config); | |||
There was a problem hiding this comment.
After removing all uses of PATH_MAX from libavrdude.h, it might also be possible to remove the header file #include which used to pull in the header file defining PATH_MAX.
That will certainly improve portability.
src/libavrdude.h
Outdated
| @@ -866,7 +866,11 @@ typedef struct { // Memory cache for a subset of cached pages | |||
| #define OFF 0 // Many contexts: reset, power, LEDs, ... | |||
| #define ON 1 // Many contexts | |||
|
|
|||
| #ifdef PATH_MAX | |||
There was a problem hiding this comment.
I have never been happy with the port[] array in the programmer structure, so I have now created PR #1699 that does away with this array and uses just a const char * pointer. As a consequence PGM_PORTLEN should no longer be needed once that PR is merged.
| const char *const *libavrdude_buildinfo = avr_get_buildinfo(); | ||
| printf("libavrdude %s\n", libavrdude_buildinfo[0]); | ||
| print_buildinfos(libavrdude_buildinfo); | ||
| } |
There was a problem hiding this comment.
Is there a good reason to use printf instead of msg_info here?
There was a problem hiding this comment.
It is a quick hack proof of concept, and I have not familiarized myself with the message API yet, so... No :-)
There was a problem hiding this comment.
No worries, take your time. For reference, here are all of them:
Lines 64 to 96 in 5c1649d
- There are
msg_*macros that just print whatever you insert. - There are
pmsg_*that printsavrdude:and then whatever you insert - There are
imsg_*that indents so that text printed on the screen will align withp_msg
And suffixes:
- There are
_infowhich prints what you insert regardless of mode - There are
noticethat will print with one or more-v's - There are
notice2that will print with two or more-v's - And more 🙂
ndim
force-pushed
the
add-build-information
branch
2 times, most recently
from
0fa4d47
to
f5bfe97
Compare
ndim
force-pushed
the
add-build-information
branch
from
4e9c7ba
to
67330c7
Compare
ndim
force-pushed
the
add-build-information
branch
2 times, most recently
from
f09ff55
to
2c53d4b
Compare
|
As build version information is system independent, build version (git branches, etc.) information it relatively simple to add. Adding information about the optional libraries and features built into this version is a bit more complex. To do that properly, we need to build a bit of build infrastructure, and then make use of that:
Aiming for a quicker, "good enough" class of solution first, then the proper one. |
|
Same here: @ndim Just an advance warning that the team have started testing with a view to release v8.0 around the w/end 17/18 Aug. If you have time to bring this PR into a shape that we can merge even partial progress that would be brill (but no worries if not). |
|
BTW, I think the merge conflict comes about b/c the |
|
Update: Issue solved already. I should read my own commit comments. The biggest problem here is that my Linux |
|
Oh, and I want a different C API for the version information. The "list of strings" as used by libgphoto2 has drawbacks. I would prefer a "list of key-value-pairs" type of interface, with keys like "gpiod" and values like "<1.4" or ">=1.4<1.8" or ">= 1.8". Such an API should be well thought out, as it should last at least 10 years. Not sure this should be rushed within the next 10 days. |
ndim
force-pushed
the
add-build-information
branch
2 times, most recently
from
2e08789
to
fedf11b
Compare
ndim
force-pushed
the
add-build-information
branch
2 times, most recently
from
fdb0603
to
ab7d9dc
Compare
ndim
force-pushed
the
add-build-information
branch
from
ab7d9dc
to
8848265
Compare
Switch from getopt(3) to getopt_long(3) and add a few long options as aliases to existing short options, e.g. "--help" and "--part" being aliases for "-?" and "-p", respectively. The getopt_long(3) function is available on GNU, BSD, and the existing msvc/getopt.[ch] already implements getopt_long() on Windows. This should cover all systems avrdude supports. Adapt the avrdude usage message shown by "-?" or "--help" to show the new long options. TODO: Adapt man page and texi manual reflecting the long options. Closes: avrdudes#1922
Add basic buildinfo ideas, quick and dirty and not tested comprehensively: * Define build information for libavrdude and the avrdude CLI tool * Add a long "--version" argument which shows a long version message. This buildinfo contains the name and version of the software component, and then a key-value-list for each buildinfo item.
ndim
force-pushed
the
add-build-information
branch
from
8848265
to
7ab2a99
Compare
The goal of this Draft PR is to develop a way to add useful build information to libavrdude and avrdude, give libavrdude users (like avrdude) access to that buildinfo, and have avrdude show the buildinfo.
The ideas for this were originally discussed in #1681 (comment) and the following comments.
This is a basic proof of concept for showing a long verbose message with build information. The verbosity, the exact information, its representation, the API and ABI are subject to discussion.
At this time, the code is based on PR #1681.
This is quick and dirty and not tested comprehensively:
Switch avrdude's
main.cfrom getopt() to getopt_long() (available on GNU, BSD, andthe existing msvc/getopt.[ch] already implement getopt_long() on
Windows)
Add
--versionargument which shows a long version message.As
-Vis already in use, the version message is available only with the long form--version.Define build information for libavrdude and the avrdude tool
buildinfo.candlibavrdude.hfor libavrdudemain.cfor avrdudeThe result looks about like