| Summary: | -gendot uses after instead of real project hierarchy | ||
|---|---|---|---|
| Product: | MPC | Reporter: | Johnny Willemsen <jwillemsen> |
| Component: | MPC | Assignee: | Chris Cleeland <cleeland_c> |
| Status: | NEW --- | ||
| Severity: | enhancement | CC: | mitza, totten_s |
| Priority: | P5 | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
|
Description
Johnny Willemsen
2008-02-01 08:35:32 CST
"after" is the keyword in MPC that establishes a project hierarchy (in the Visual Studio "dependencies" sense). Is your proposal to use sharedname/staticname and libs to determine a hierarchy? would it maybe be possible to generate a dot file of the hierarchy of the project itself, so just the name of the full projects? That can then be used to set the afters correctly by the user. mostly useful when people have messed up their mpc files (In reply to comment #2) > would it maybe be possible to generate a dot file of the hierarchy of the > project itself, so just the name of the full projects? That can then be used to > set the afters correctly by the user. mostly useful when people have messed up > their mpc files > I'm not sure what this means. What determines the "hierarchy of the project itself"? Is this just a list of relative paths to the projects? What's the point using of GraphViz on a list? (In reply to comment #3) > I'm not sure what this means. What determines the "hierarchy of the project > itself"? Is this just a list of relative paths to the projects? What's the > point using of GraphViz on a list? your exe is using for example two app libs, one of them uses portableserver, that uses tao, that ace, etc. For one project there is always a list but if you take all base projects then you will have a hierarchy lowering priority (In reply to comment #4) > your exe is using for example two app libs, one of them uses portableserver, > that uses tao, that ace, etc. For one project there is always a list but if you > take all base projects then you will have a hierarchy > OK, so it's determined by the libs / {static,shared}name relationship, like I was asking in comment #1. I think this would be possible but I'm sure there would be some tricky cases that MPC wouldn't be able to handle. For example, a project that builds a library could leave it in "." (no libout) and then an executable could locate this library using an environment variable like libpaths += $(FOO_ROOT)/library1. MPC would have no way of knowing that $(FOO_ROOT)/library1 resolved to the directory where the library was built. If MPC has knowledge of the libs / {static,shared}name relationship maybe "after" becomes unnecessary for most cases? Perhaps there could be a switch like "-autoafter" to automatically determine the "after" relationships (when possible). (In reply to comment #6) > (In reply to comment #4) > I think this would be possible but I'm sure there would be some tricky cases > that MPC wouldn't be able to handle. For example, a project that builds a > library could leave it in "." (no libout) and then an executable could locate > this library using an environment variable like libpaths += > $(FOO_ROOT)/library1. MPC would have no way of knowing that > $(FOO_ROOT)/library1 resolved to the directory where the library was built. Yet, there can be tricky things, but the use cases where I am consider to use it are not using all these tricky things. > If MPC has knowledge of the libs / {static,shared}name relationship maybe > "after" becomes unnecessary for most cases? Perhaps there could be a switch > like "-autoafter" to automatically determine the "after" relationships (when > possible). It will not work for the custom_only projects that don't result into an library, for example the idl projects in tao. at least having a graph of the projects will make it visible that the exe is dependent on the idl custom project maybe we should convert -gendot to a real project template. we could for example then say that a library is a circle, executable a box, add colors, etc This is not really a bug. It's more of an enhancement. (In reply to comment #8) > maybe we should convert -gendot to a real project template. we could for > example then say that a library is a circle, executable a box, add colors, etc > In that case it could be an enhancement to the existing -type html. Maybe the "libs" for each project would be hyperlinked and the back-links would be shown too. Figuring out those back-links would probably be enough to build the graphical view, which would probably end up in the workspace's html file. |