Semi-returning (and in need of some help)



  • First off: I'm sortakindabackish (posts will be occasional, reading will be random, don't expect me to follow all the things).

    The reason for my return: an assignment that I'm 99% complete with but am unable to finish, because of a hand-in requirements conflict with the professor. The assignment's actually a project (build a microcontroller board, write firmware for it, write lab report for same), and I have the board complete, the firmware written and working, and the lab report almost done (at last!), save for one thing.

    My professor wants a single source file for the firmware, but I, not knowing it at the time, decided to at least somewhat modularize the firmware for this. I wrote it in C btw (which is about the best you can do on 8051s anyway, but I'm not sure if the prof was expecting C or assembler) with a standard Unixy Makefile (adequate for something small like this -- wasn't going to fool around with having to get all the toolchain bits set up for CMake). Is there some sort of general purpose tool I can use to selectively combine all my stuff into a single, sensible source file? Catting together preprocessed output meets the single criteria, but not the sensible as what-passes-for-system-headers get sucked in at a minimum, leaving a bunch of useless-to-the-prof stuff in the output that I don't think would be gracious to hand in to him. I was thinking that there would be something out there that can evaluate #include "..."s while leaving #include <...>s and other preprocessor stuff untouched, as well as not introducing annoying things like #line...

    (And before you suggest VMs or Docker or whathaveyou to deliver a machine image capable of running my Makefile -- 1) I'm not terribly familiar with any of that, 2) I have no reason to expect or suspect that the professor is any more familiar with those tools than I am, and 3) he also wants a source listing as an appendix to the lab report.)

    If worse comes to worse, I'll punt and hand him a zipball + break the sourcecode listing in the report down by file, but that's a last resort. (Not that he'll be likely to have much luck compiling anyway, but embedded compilers are not known for inter-compiler portability even on the same platform triple, so I suspect he'll be understanding there at least.)



  • @tarunik GCC has a C backend. Maybe you can compile C to C. (good to see you!)



  • @tarunik Are you talking about 5 modules or 500?

    Assuming the firmware isn't huge, honestly I'd just do it manually and swallow the productivity hit of working on it.



  • @blakeyrat 5 modules (thankfully not 500!). I'd rather just hand in a zipball than do this manually BTW -- although this is inspiring me to take a deeper look at what could be possible via preprocessor shenanigans...


  • Notification Spam Recipient

    @tarunik said in Semi-returning (and in need of some help):

    follow all the things

    It's actually calmed down quite a bit recently, once a few categories were incepted....


  • Notification Spam Recipient

    @tarunik said in Semi-returning (and in need of some help):

    leaving a bunch of useless-to-the-prof stuff in the output that I don't think would be gracious to hand in to him.

    Well then he shouldn't have made that a requirement, should he?

    Edit: Honestly, if he just wants a printout, there's nothing wrong with smushing them out with a file marker divider thing.

    In theory, scrounge all your external includes, then order the listing according to their include order in your source. I would not expect the need to include external files.

    Cursory google search seems to indicate a tool like CIL might help, but if it's less than ten files I'd probably not bother.



  • I think I'd cat all the C files together, cut/paste all the #includes to the beginning of the mess, and eliminate the duplicates. Yeah, it's manual, but it doesn't seem like it would be all that much work for just a few files.



  • Haven't done enough C to help you, just wanted to welcome you back!



  • @hardwaregeek said in Semi-returning (and in need of some help):

    I think I'd cat all the C files together, cut/paste all the #includes to the beginning of the mess, and eliminate the duplicates. Yeah, it's manual, but it doesn't seem like it would be all that much work for just a few files.

    This, essentially.

    Assuming the headers have guards, you can maybe automate removal of duplicates with sunifdef (it's a tool to eliminate #ifdef-blocks. Header-guards should qualify).

    Edit: another way is to just concat all your headers first (order matters here, if interdependencies between the headers are a thing), and then append all the sources afterwards. At that point you just need to strip all the local #includes.



  • @tsaukpaetra said in Semi-returning (and in need of some help):

    a few categories were incepted

    How about inceive(d), by analogy with conception/conceive?



  • @cvi said in Semi-returning (and in need of some help):

    Edit: another way is to just concat all your headers first (order matters here, if interdependencies between the headers are a thing), and then append all the sources afterwards. At that point you just need to strip all the local #includes.

    I think this is the approach I'll be taking here -- there are no non-trivial inter-header dependencies, thankfully. Now, to figure out stripping the local #includes...



  • Whew! If you're curious -- it turns out the HEADERS in my Makefile were in the right order anyway, so I was able to just:

    cat $(HEADERS) $(SRCS) | grep -Ev '#include "[^"]"' > file.out
    

    more or less and get something usable that way.