Timeline for What are good ways to organize input files (Makefiles, SConstruct, CMakeLists.txt, etc.) to build automation software?
Current License: CC BY-SA 3.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 6, 2012 at 4:52 | comment | added | Geoff Oxberry | Yeah, that's what I was trying to do when I filtered out a lot of files, because the SConstruct dependency parser picks up a huge number of files. So I filtered those out, and used the Python script at the link to make a dotfile so I could visualize the parts of the DAG that I thought were important. It worked, and I got a small enough graph so I could pick out what was important, but I didn't see a whole lot I could use there. I suspect this strategy is a lot easier to use with Make because it's easier to find repeated rules in Makefiles, as you can see from the source I posted. | |
| Feb 6, 2012 at 4:44 | comment | added | snakehiss | You don't need to look at the entire DAG. You can just go through the Makefile of SConstruct file and target the worst parts. Identify what they are doing rework the implicit DAG and break it out. Move general rules into separate files. Organize according to data/functions/target with high cohesion like you would with a regular programming language. | |
| Feb 5, 2012 at 5:45 | comment | added | Geoff Oxberry | +1 for the idea of looking at the DAG. I agree that there are potential opportunities to refactor there. Visualizing the DAG can be a pain in the ass. For Makefiles, there's Makefile::GraphViz, and for SCons, there's a Python script here that may require a bit of hacking, depending on the project. The graphs that script gave me were sometimes heinously large, so I found that I had to filter carefully what I wanted to visualize. | |
| Feb 4, 2012 at 18:20 | history | answered | snakehiss | CC BY-SA 3.0 |