Dmitri;
It might be possible to remove the current path issues with the use of
graphviz. If the dot interface was encapsulated in a class, then when doxygen
is run it can determine which path format is used by dot and which is native to
the invoking shell/system. Using the appropriate class object then does the
necessary conversion.
Suppose there are:
class superPath {
virtual string convertPath(string path) = 0;
}
class unixTounix: superPath { }class unixToDOS : superPath { }
class DOSToUnix : superPath { }
class DOSToDOS : superPath { }
then at runtime initialization create a tmpfile and retrieve its absolute path.
That determines the path environment for doxygen. Call a dot method requiring a
path. If it is rejected or not rejected determines the path used by graphviz.
Making the class instance global allows conversion throughout doxygen.
I don't know the code of anything, but just as a thought:
int decision = (doxygen_path_unix)? 0: 1;
decision |= ((dot(path))? decision: !decision) << 1;
switch (decision) {
case 00:
globalThing = new unixTounix();
break;
case 01:
globalThing = new unixToDOS();
break;
case 10:
globalThing = new DOSTounix();
break;
case 11:
globalThing = new DOSToDOS();
break;
}
Thereafter: dot(globalThing->convertPath(path));
This is not to say that it should, could, or would be done or done this way.
Just a thought
Maybe in some future release?
art
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Doxygen-users mailing list
Doxygen-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/doxygen-users
