Open marikgoldstein opened 7 years ago
Also seems like getting familiar with the hake build system beyond the depth of adding a user program is worth the time.
Ok I pushed to a new branch called Markfile. I'll continue my experimentation there.
In addition to the Markfile (which at this point does not yet have useful information), I generate a file called all_hakepaths.txt. This just has a simple list of all the hakefiles in the source tree.
The list we are going after will contain .c, .h, and other files (like flounder interfaces) that are referenced by a subset of these hakefiles.
child of #49
can we use the tracing infrastructure to accomplish this?
refs: http://www.barrelfish.org/publications/stolz-grest-dslab-tracing.pdf https://github.com/Harvard-PRINCESS/Guppy/tree/dev/tools/tracing
network has to come up for these tools to work, however :(
I have spent the day learning the hake build system (and haskell). I have learned quite a lot. However, matching the set of all hakefiles (and thus, the .c and .h files they reference) against the list of active modules for a particular build (found in its hake/menu.lst) is non-trivial.
Most of the hake flow that generates the Makefile is located in hake/Main.hs, with some key macros (hacros) define in hake/RuleDefs.hs
At this point I have rigged a version of Main.hs to write a "Markfile" where it also writes the Makefile body. At this point, one has access to a parsed version of each hakefile and can access things like a list of c files, includes, and corresponding targets.
ps I love Haskell now.