Menu

#207 OnBC: More than 16 includes are silently ignored

open
OnBoard C (71)
5
2008-04-11
2008-04-09
No

If a .c file includes more than 16 other files, only the first 16 are checked when deciding if the file needs to be rebuilt. The limit itself seems to be ok but the silent ignoring is not ok. OnBoardC should warn at least once (but preferably not all the time) that you have gone over the limit.

Discussion

  • Steve Little

    Steve Little - 2008-04-09

    Logged In: YES
    user_id=583634
    Originator: NO

    Second.

    Doesn't sound like it would be hard to fix...

     
  • John Wilund

    John Wilund - 2008-04-09

    Logged In: YES
    user_id=574706
    Originator: NO

    I second this and move this to tasks.

    Lincoln, should I assign you as PoC for this one?

     
  • John Wilund

    John Wilund - 2008-04-09
    • labels: 587913 --> OnBoard C
    • milestone: 349193 -->
    • summary: More than 16 includes are silently ignored --> OnBC: More than 16 includes are silently ignored
     
  • John Wilund

    John Wilund - 2008-04-11
    • assigned_to: nobody --> a1291762
     
  • John Wilund

    John Wilund - 2008-04-28

    Logged In: YES
    user_id=574706
    Originator: NO

    Alerting once per .proj build? or once per build session? (within the same day?)
    /John

     
  • John Wilund

    John Wilund - 2008-04-29

    Logged In: YES
    user_id=574706
    Originator: NO

    Alerting once per .proj build? or once per build session? (within the same day?)
    /John

     
  • Lincoln Ramsay

    Lincoln Ramsay - 2008-04-30

    Logged In: YES
    user_id=736434
    Originator: YES

    The list of includes is generated when the .c file is re-compiled (and then cached so that future runs don't need to parse the .c file just to see if it's includes have changed).

    Getting this to fire with a message like "Changing foo.h will not cause bar.c to be re-compiled" is easy enough... but it's happening once per "instance" which in my contrived test means pressing ok 4 times per file (for ~20 files).

    I'm thinking that perhaps the best way to report all of this is once, at the end of a build. Alternatively, files that have too many includes could just be forced to re-compile all of the time. There's an int that holds the number of include and if this is greater than the maximum, the file would be forced to re-build. This could also be detected when loading the project (so perhaps that would be the time to put up a warning dialog). Note that setting the int to larger than the maximum might cause older versions of OnBoardC to crash when loading the project (it's assumed the number is never greater than the maximum).

    Note the actual warning will be a bit tricky because the code where this triggers has the source file and the include file but not any intermediate files (eg. my test had foo.c #include "all.h" which had ~20 #include lines and there didn't seem to be an "include stack" for me to track through).

    Perhaps even a general, once-off "This project contains source files that include more than 16 files. These files will be forced to re-build" message on project load, tied to a flag on the project that's set (to prevent the warning coming up all the time) and only coming up again if the error condition is cleared and re-introduced. I'm not sure if there's any "reserved bits" available in the project header or if a new project version needs to be created to support this.

    At a minimum, silently forcing the rebuilding of files that include more than 16 headers can be done without versioning issues and resolves the most obvious problem likely to be encountered, "why doesn't foo.c rebuild when I touch bar.h?"

     

Log in to post a comment.