-
Notifications
You must be signed in to change notification settings - Fork 145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add build information to libavrdude and avrdude and display it #1698
base: main
Are you sure you want to change the base?
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well spotted!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a good reason to use printf instead of msg_info here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No worries, take your time. For reference, here are all of them:
Lines 64 to 96 in 5c1649d
// Shortcuts | |
#define msg_ext_error(...) avrdude_message2(stderr, __LINE__, __FILE__, __func__, 0, MSG_EXT_ERROR, __VA_ARGS__) | |
#define msg_error(...) avrdude_message2(stderr, __LINE__, __FILE__, __func__, 0, MSG_ERROR, __VA_ARGS__) | |
#define msg_warning(...) avrdude_message2(stderr, __LINE__, __FILE__, __func__, 0, MSG_WARNING, __VA_ARGS__) | |
#define msg_info(...) avrdude_message2(stderr, __LINE__, __FILE__, __func__, 0, MSG_INFO, __VA_ARGS__) | |
#define msg_notice(...) avrdude_message2(stderr, __LINE__, __FILE__, __func__, 0, MSG_NOTICE, __VA_ARGS__) | |
#define msg_notice2(...) avrdude_message2(stderr, __LINE__, __FILE__, __func__, 0, MSG_NOTICE2, __VA_ARGS__) | |
#define msg_debug(...) avrdude_message2(stderr, __LINE__, __FILE__, __func__, 0, MSG_DEBUG, __VA_ARGS__) | |
#define msg_trace(...) avrdude_message2(stderr, __LINE__, __FILE__, __func__, 0, MSG_TRACE, __VA_ARGS__) | |
#define msg_trace2(...) avrdude_message2(stderr, __LINE__, __FILE__, __func__, 0, MSG_TRACE2, __VA_ARGS__) | |
#define pmsg_ext_error(...) avrdude_message2(stderr, __LINE__, __FILE__, __func__, MSG2_PROGNAME|MSG2_FUNCTION|MSG2_FILELINE|MSG2_TYPE|MSG2_FLUSH, MSG_EXT_ERROR, __VA_ARGS__) | |
#define pmsg_error(...) avrdude_message2(stderr, __LINE__, __FILE__, __func__, MSG2_PROGNAME|MSG2_FUNCTION|MSG2_FILELINE|MSG2_TYPE|MSG2_FLUSH, MSG_ERROR, __VA_ARGS__) | |
#define pmsg_warning(...) avrdude_message2(stderr, __LINE__, __FILE__, __func__, MSG2_PROGNAME|MSG2_FUNCTION|MSG2_FILELINE|MSG2_TYPE|MSG2_FLUSH, MSG_WARNING, __VA_ARGS__) | |
#define pmsg_info(...) avrdude_message2(stderr, __LINE__, __FILE__, __func__, MSG2_PROGNAME|MSG2_FLUSH, MSG_INFO, __VA_ARGS__) | |
#define pmsg_notice(...) avrdude_message2(stderr, __LINE__, __FILE__, __func__, MSG2_PROGNAME|MSG2_FLUSH, MSG_NOTICE, __VA_ARGS__) | |
#define pmsg_notice2(...) avrdude_message2(stderr, __LINE__, __FILE__, __func__, MSG2_PROGNAME|MSG2_FLUSH, MSG_NOTICE2, __VA_ARGS__) | |
#define pmsg_debug(...) avrdude_message2(stderr, __LINE__, __FILE__, __func__, MSG2_PROGNAME|MSG2_FLUSH, MSG_DEBUG, __VA_ARGS__) | |
#define pmsg_trace(...) avrdude_message2(stderr, __LINE__, __FILE__, __func__, MSG2_PROGNAME|MSG2_FLUSH, MSG_TRACE, __VA_ARGS__) | |
#define pmsg_trace2(...) avrdude_message2(stderr, __LINE__, __FILE__, __func__, MSG2_PROGNAME|MSG2_FLUSH, MSG_TRACE2, __VA_ARGS__) | |
#define imsg_ext_error(...) avrdude_message2(stderr, __LINE__, __FILE__, __func__, MSG2_INDENT1|MSG2_FLUSH, MSG_EXT_ERROR, __VA_ARGS__) | |
#define imsg_error(...) avrdude_message2(stderr, __LINE__, __FILE__, __func__, MSG2_INDENT1|MSG2_FLUSH, MSG_ERROR, __VA_ARGS__) | |
#define imsg_warning(...) avrdude_message2(stderr, __LINE__, __FILE__, __func__, MSG2_INDENT1|MSG2_FLUSH, MSG_WARNING, __VA_ARGS__) | |
#define imsg_info(...) avrdude_message2(stderr, __LINE__, __FILE__, __func__, MSG2_INDENT2|MSG2_FLUSH, MSG_INFO, __VA_ARGS__) | |
#define imsg_notice(...) avrdude_message2(stderr, __LINE__, __FILE__, __func__, MSG2_INDENT2|MSG2_FLUSH, MSG_NOTICE, __VA_ARGS__) | |
#define imsg_notice2(...) avrdude_message2(stderr, __LINE__, __FILE__, __func__, MSG2_INDENT2|MSG2_FLUSH, MSG_NOTICE2, __VA_ARGS__) | |
#define imsg_debug(...) avrdude_message2(stderr, __LINE__, __FILE__, __func__, MSG2_INDENT2|MSG2_FLUSH, MSG_DEBUG, __VA_ARGS__) | |
#define imsg_trace(...) avrdude_message2(stderr, __LINE__, __FILE__, __func__, MSG2_INDENT2|MSG2_FLUSH, MSG_TRACE, __VA_ARGS__) | |
#define imsg_trace2(...) avrdude_message2(stderr, __LINE__, __FILE__, __func__, MSG2_INDENT2|MSG2_FLUSH, MSG_TRACE2, __VA_ARGS__) | |
#define term_out(...) avrdude_message2(stdout, __LINE__, __FILE__, __func__, MSG2_FLUSH, MSG_INFO, __VA_ARGS__) | |
#define fmsg_out(fp, ...) avrdude_message2(fp, __LINE__, __FILE__, __func__, MSG2_FLUSH, MSG_INFO, __VA_ARGS__) |
- 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
_info
which prints what you insert regardless of mode - There are
notice
that will print with one or more-v
's - There are
notice2
that will print with two or more-v
's - And more 🙂
0fa4d47
to
f5bfe97
Compare
4e9c7ba
to
67330c7
Compare
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. |
2e08789
to
fedf11b
Compare
fdb0603
to
ab7d9dc
Compare
ab7d9dc
to
8848265
Compare
ad4c30c
to
3aad70d
Compare
That this PR now building on the #1936 PR which now introduces the long options like |
Switch the command line argument parser 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.
Next: Create a output messages file, and a C include file. TODO: Name the generated files buildinfo-include.c and buildinfo-messages.txt
* use the same file names for messages and C code * print the same "Configuration summary" output
8f900ca
to
6c6b816
Compare
7040fb2
to
0fc8e8e
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.c
from getopt() to getopt_long() (available on GNU, BSD, andthe existing msvc/getopt.[ch] already implement getopt_long() on
Windows)
Add
--version
argument which shows a long version message.As
-V
is already in use, the version message is available only with the long form--version
.Define build information for libavrdude and the avrdude tool
buildinfo.c
andlibavrdude.h
for libavrdudemain.c
for avrdudeThe result looks about like