Skip to content
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 option to generate #defines for the Signal names when generating C source. #548

Merged

Conversation

guy-radford-sunswap
Copy link
Contributor

This PR adds a command line option to include #defines for the CAN Signal names.

Format

#define DATABASE_NAME_MESSAGE_NAME_SIGNAL_NAME "signal_name"

This PR for issue: #547

@guy-radford-sunswap guy-radford-sunswap marked this pull request as ready for review April 20, 2023 10:34
@coveralls
Copy link

coveralls commented Apr 20, 2023

Pull Request Test Coverage Report for Build 4765020020

  • 8 of 8 (100.0%) changed or added relevant lines in 1 file are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage increased (+0.006%) to 93.988%

Totals Coverage Status
Change from base Build 4652812639: 0.006%
Covered Lines: 7066
Relevant Lines: 7518

💛 - Coveralls

Copy link
Member

@andlaus andlaus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In principle I'm not opposed to this, but I have some trouble in seeing the use case: wouldn't it be easier to just write "signal_name" instead of DATABASE_NAME_MESSAGE_NAME_SIGNAL_NAME in your code?

README.rst Outdated

.. code-block:: text

$ python3 -m cantools generate_c_source --include_signal_names tests/files/dbc/motohawk.dbc
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that option should use minuses instead of underscores (--include-signal-names) and it should probably be called --generate-signal-name-macros. That said, I don't really see any harm in including these macros unconditionally, if it is decided that we want them...

@@ -0,0 +1,175 @@
/**
Copy link
Member

@andlaus andlaus Apr 20, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this, and the corresponding .c file in this PR, seems to be spurious: It should be generated as part of running the tests?

@guy-radford-sunswap
Copy link
Contributor Author

Updated based on feedback. Thank you

@@ -0,0 +1,211 @@
/**
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you also need to remove this file from the PR...

@andlaus
Copy link
Member

andlaus commented Apr 21, 2023

thanks. Can you please explain what the advantage of these macros relative to just using the strings with the names directly is?

@guy-radford-sunswap
Copy link
Contributor Author

Using "signal_name" is open typos and errors, whereas a #define will allow the IDE to predict and highlight errors, also a static analyzer will also detect this before you get to running the tests.

@andlaus
Copy link
Member

andlaus commented Apr 21, 2023

fair enough. can you put the message names through the same treatment?

@guy-radford-sunswap
Copy link
Contributor Author

Yes sure :) Do you want the message(frame) names to be optional too or lumped in with the signal names?

@andlaus
Copy link
Member

andlaus commented Apr 21, 2023

As I see it there's no reason not to generate all of these macros unconditionally. (I might have missed something...)

@guy-radford-sunswap
Copy link
Contributor Author

Makes sense to me... other then then files will be a little bigger, but the compiler will removed anything that is unsed.

@andlaus
Copy link
Member

andlaus commented Apr 21, 2023

disk storage is cheap these days ;) (compile time might be another issue, but I doubt that this will be more than a few milliseconds even for pretty large databases.)

@guy-radford-sunswap
Copy link
Contributor Author

Done

  • Added Frame Name Macros
  • Added Signal Name Macros
  • Updated Test expect files to support auto-generation of the above Macros.

#define VEHICLE_RT_SB_GPS_TIME_VALIDITY_GPS_TIME "Validity_GPS_Time"
#define VEHICLE_RT_SB_GPS_TIME_VALIDITY_GPS_WEEK "Validity_GPS_Week"
#define VEHICLE_RT_SB_GPS_TIME_ACCURACY_GPS_TIME "Accuracy_GPS_Time"
#define VEHICLE_RT_SB_GPS_TIME_GPS_TIME "GPS_Time"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hm, I suppose prefixing these macros with NAME_ (or using a _NAME postfix) would probably be a good idea to avoid naming collisions with other stuff...

@andlaus
Copy link
Member

andlaus commented Apr 21, 2023

all green, let's merge. Thanks for your contribution.

@andlaus andlaus merged commit 04ad96f into cantools:master Apr 21, 2023
13 checks passed
@guy-radford-sunswap guy-radford-sunswap deleted the add_define_for_signal_name branch January 3, 2024 11:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants