Putting a comment after an int in prj.conf causes an error

There appears to be a bug with commenting in prj.conf. If I do this:

# This is the appearance of the device from the BLE SIG Assigned Numbers List (384 is general remote co
CONFIG_BT_DEVICE_APPEARANCE=384
...it works fine. If I do this:
CONFIG_BT_DEVICE_APPEARANCE=384               # This is the appearance of the device from the BLE SIG Assigned Numbers List (384 is general remote co
...it does not. The problem appears to be comments that follow the assignment on the same line. This is not a problem when the config is boolean or a string.
CONFIG_BT_DIS_FW_REV_STR="FD-98562-01.0000000000"   # This is the SmartPac Firmware part number for the particular application. It's in the formate o
...works fine, as an example.
Is Team Nordic aware of the bug, and are there any plans to fix it?
Parents
  • Hi,

    Yes, we are aware of this being the case. I guess everything after the equals sign is considered a part of the value, unless you explicitly end the value using a final quotation mark. Another thing that would separate KConfig from what you would eg. expect from C, is that a using spaces between the equals sign can be an issue as well.

    But I wouldn't think of any of these as a bug per se - it is how to parser works. It has some limitations but that is typically considered fine. You can eg. add the comment on a different line, and don't need the spaces.

    I guess it would be better if the parser looked for this issue, to make the error codes easier to work with. I haven't heard of any plans to fix this. 

    Regards,

    Elfving

Reply
  • Hi,

    Yes, we are aware of this being the case. I guess everything after the equals sign is considered a part of the value, unless you explicitly end the value using a final quotation mark. Another thing that would separate KConfig from what you would eg. expect from C, is that a using spaces between the equals sign can be an issue as well.

    But I wouldn't think of any of these as a bug per se - it is how to parser works. It has some limitations but that is typically considered fine. You can eg. add the comment on a different line, and don't need the spaces.

    I guess it would be better if the parser looked for this issue, to make the error codes easier to work with. I haven't heard of any plans to fix this. 

    Regards,

    Elfving

Children
No Data
Related