i am facing 20,000 lines of code. I inherited them from a former phd student who wrote the code but didn't care to show the structure of what he wrote. Now i have to guess what the dependencies are, i mean, what the main program is and how the subroutines are connected to each other.
I wonder if there is a software/technicque that helps me do that in Fortran. I accept any ideas. I hope you understand my inquiry. Regards,
On Jun 14, 6:09 pm, VICTOR <victor.hera...@gmail.com> wrote:
> Hi,
> i am facing 20,000 lines of code. I inherited them from a former phd > student who wrote the code but didn't care to show the structure of > what he wrote. Now i have to guess what the dependencies are, i mean, > what the main program is and how the subroutines are connected to each > other.
> I wonder if there is a software/technicque that helps me do that in > Fortran. I accept any ideas. I hope you understand my inquiry. > Regards,
> On Jun 14, 6:09 pm, VICTOR <victor.hera...@gmail.com> wrote:
> > Hi,
> > i am facing 20,000 lines of code. I inherited them from a former phd > > student who wrote the code but didn't care to show the structure of > > what he wrote. Now i have to guess what the dependencies are, i mean, > > what the main program is and how the subroutines are connected to each > > other.
> > I wonder if there is a software/technicque that helps me do that in > > Fortran. I accept any ideas. I hope you understand my inquiry. > > Regards,
Thank you. I am dad to tell it's fortran 90. A funny thing: he old me to read about subroutines in the first chapter of a book. I forgtot to mention what he should have done. Funny isn't it ?
On Jun 14, 9:09 am, VICTOR <victor.hera...@gmail.com> wrote:
> Hi,
> i am facing 20,000 lines of code. I inherited them from a former phd > student who wrote the code but didn't care to show the structure of > what he wrote. Now i have to guess what the dependencies are, i mean, > what the main program is and how the subroutines are connected to each > other.
> I wonder if there is a software/technicque that helps me do that in > Fortran. I accept any ideas. I hope you understand my inquiry. > Regards,
> Victor
I wonder if Doxygen can help. The Doxygen web page says, "You can configure doxygen to extract the code structure from undocumented source files." See http://www.stack.nl/~dimitri/doxygen/.
>I wonder if Doxygen can help. The Doxygen web page says, "You can >configure doxygen to extract the code structure from undocumented >source files." See http://www.stack.nl/~dimitri/doxygen/.
And it squares circles, whitens your teeth and makes you irresistable to the opposite sex.
That claim is obviously impossible to deliver. However, it MAY be able to extract the call chain, which is a feasible task. It also isn't hard to write a crude parser that will do the job, though is a little painful if you have to be able to detect functions that are declared as such merely by being called.
Alternatively, and this is the way I would proceed, split the code apart into modules and procedures, compile each separately and use nm or elfdump on the object files. The write a program to display that conveniently. Tedious, but not difficult.
> >I wonder if Doxygen can help. The Doxygen web page says, "You can > >configure doxygen to extract the code structure from undocumented > >source files." Seehttp://www.stack.nl/~dimitri/doxygen/.
> And it squares circles, whitens your teeth and makes you irresistable > to the opposite sex.
> That claim is obviously impossible to deliver. However, it MAY be > able to extract the call chain, which is a feasible task. It also > isn't hard to write a crude parser that will do the job, though is > a little painful if you have to be able to detect functions that > are declared as such merely by being called.
> Alternatively, and this is the way I would proceed, split the code > apart into modules and procedures, compile each separately and use > nm or elfdump on the object files. The write a program to display > that conveniently. Tedious, but not difficult.
> Regards, > Nick Maclaren.
DOYGEN is capable of generating call graphs (for each routine: which routines are called, by which routines is it called itself). I am not quite sure what it can do with functions that are not explicitly declared, but it seems to be a nice enough tool.
In article <c29a003d-d24c-496a-b13f-d2703f212...@k2g2000yql.googlegroups.com>, Arjen Markus <arjen.mar...@wldelft.nl> wrote:
>DOYGEN is capable of generating call graphs (for each routine: >which routines are called, by which routines is it called itself). >I am not quite sure what it can do with functions that are not >explicitly declared, but it seems to be a nice enough tool.
As I said.
What it CANNOT do is to "extract the code structure from undocumented source files." Whether it does anything sensible with procedures passed as arguments, I don't know,, but it assuredly cannot do anything useful with programs that use procedure variables in arbitrary ways. To achieve that, it would have to solve the halting problem.
My objection is to its hype, not its functionality.
>>> I wonder if Doxygen can help. The Doxygen web page says, "You can >>> configure doxygen to extract the code structure from undocumented >>> source files." Seehttp://www.stack.nl/~dimitri/doxygen/. >> And it squares circles, whitens your teeth and makes you irresistable >> to the opposite sex.
>> That claim is obviously impossible to deliver. However, it MAY be >> able to extract the call chain, which is a feasible task. It also >> isn't hard to write a crude parser that will do the job, though is >> a little painful if you have to be able to detect functions that >> are declared as such merely by being called.
>> Alternatively, and this is the way I would proceed, split the code >> apart into modules and procedures, compile each separately and use >> nm or elfdump on the object files. The write a program to display >> that conveniently. Tedious, but not difficult.
>> Regards, >> Nick Maclaren.
> DOYGEN is capable of generating call graphs (for each routine: > which routines are called, by which routines is it called itself). > I am not quite sure what it can do with functions that are not > explicitly declared, but it seems to be a nice enough tool.
> Regards,
> Arjen
Arjen,
Which version of doxygen do you use?
I did not get version 1.4.7 to work on Red Hat Enterprise Linux 5.3. I used the rpm.
> >>> I wonder if Doxygen can help. The Doxygen web page says, "You can > >>> configure doxygen to extract the code structure from undocumented > >>> source files." Seehttp://www.stack.nl/~dimitri/doxygen/. > >> And it squares circles, whitens your teeth and makes you irresistable > >> to the opposite sex.
> >> That claim is obviously impossible to deliver. However, it MAY be > >> able to extract the call chain, which is a feasible task. It also > >> isn't hard to write a crude parser that will do the job, though is > >> a little painful if you have to be able to detect functions that > >> are declared as such merely by being called.
> >> Alternatively, and this is the way I would proceed, split the code > >> apart into modules and procedures, compile each separately and use > >> nm or elfdump on the object files. The write a program to display > >> that conveniently. Tedious, but not difficult.
> >> Regards, > >> Nick Maclaren.
> > DOYGEN is capable of generating call graphs (for each routine: > > which routines are called, by which routines is it called itself). > > I am not quite sure what it can do with functions that are not > > explicitly declared, but it seems to be a nice enough tool.
> > Regards,
> > Arjen
> Arjen,
> Which version of doxygen do you use?
> I did not get version 1.4.7 to work on Red Hat Enterprise Linux 5.3. I > used the rpm.
> So I only use the style file.
> Kind regards,
> Jan Gerrit Kootstra- Tekst uit oorspronkelijk bericht niet weergeven -
> - Tekst uit oorspronkelijk bericht weergeven -
I saw a demonstration by a colleague last week. He used version 1.5.9 on Windows and that works fine.
I have tried it myself just now: you have to set a bunch of configuration options and it does not seem to like .f files very much, but it does extract information in modules.
I am just experimenting right now and I will have to ask my colleague what options he used exactly ...
> > >>> I wonder if Doxygen can help. The Doxygen web page says, "You can > > >>> configure doxygen to extract the code structure from undocumented > > >>> source files." Seehttp://www.stack.nl/~dimitri/doxygen/. > > >> And it squares circles, whitens your teeth and makes you irresistable > > >> to the opposite sex.
> > >> That claim is obviously impossible to deliver. However, it MAY be > > >> able to extract the call chain, which is a feasible task. It also > > >> isn't hard to write a crude parser that will do the job, though is > > >> a little painful if you have to be able to detect functions that > > >> are declared as such merely by being called.
> > >> Alternatively, and this is the way I would proceed, split the code > > >> apart into modules and procedures, compile each separately and use > > >> nm or elfdump on the object files. The write a program to display > > >> that conveniently. Tedious, but not difficult.
> > >> Regards, > > >> Nick Maclaren.
> > > DOYGEN is capable of generating call graphs (for each routine: > > > which routines are called, by which routines is it called itself). > > > I am not quite sure what it can do with functions that are not > > > explicitly declared, but it seems to be a nice enough tool.
> > > Regards,
> > > Arjen
> > Arjen,
> > Which version of doxygen do you use?
> > I did not get version 1.4.7 to work on Red Hat Enterprise Linux 5.3. I > > used the rpm.
> > So I only use the style file.
> > Kind regards,
> > Jan Gerrit Kootstra- Tekst uit oorspronkelijk bericht niet weergeven -
> > - Tekst uit oorspronkelijk bericht weergeven -
> I saw a demonstration by a colleague last week. He used version 1.5.9 > on > Windows and that works fine.
> I have tried it myself just now: you have to set a bunch of > configuration > options and it does not seem to like .f files very much, but it does > extract information in modules.
> I am just experimenting right now and I will have to ask my colleague > what options he used exactly ...
> Regards,
> Arjen- Tekst uit oorspronkelijk bericht niet weergeven -
> - Tekst uit oorspronkelijk bericht weergeven -
Ah, the secret is in the \file comment: include something like
! ! \file filename.f
in the source files to get DOXYGEN to parse them and produce an overview of the routines it contains. That is the minimum requirement it seems (unless it contains modules).
> On Jun 14, 9:09 am, VICTOR <victor.hera...@gmail.com> wrote:
> > Hi,
> > i am facing 20,000 lines of code. I inherited them from a former phd > > student who wrote the code but didn't care to show the structure of > > what he wrote. Now i have to guess what the dependencies are, i mean, > > what the main program is and how the subroutines are connected to each > > other.
> > I wonder if there is a software/technicque that helps me do that in > > Fortran. I accept any ideas. I hope you understand my inquiry. > > Regards,
> > Victor
> I wonder if Doxygen can help. The Doxygen web page says, "You can > configure doxygen to extract the code structure from undocumented > source files." Seehttp://www.stack.nl/~dimitri/doxygen/.
> Damian
Yes, it does that by generating call trees. The output can be in the form of HTML pages showing the headers of the routines and the list of routines that it calls and vice versa. (A colleague showed some results of DOXYGEN last week - I have not used it myself yet)
> In article > <c29a003d-d24c-496a-b13f-d2703f212...@k2g2000yql.googlegroups.com>, > Arjen Markus <arjen.mar...@wldelft.nl> wrote:
>>DOYGEN is capable of generating call graphs (for each routine: >>which routines are called, by which routines is it called itself). >>I am not quite sure what it can do with functions that are not >>explicitly declared, but it seems to be a nice enough tool.
> As I said.
> What it CANNOT do is to "extract the code structure from undocumented > source files." Whether it does anything sensible with procedures > passed as arguments, I don't know,, but it assuredly cannot do > anything useful with programs that use procedure variables in > arbitrary ways. To achieve that, it would have to solve the halting > problem.
Well, it probably *can* extract a subset of the true call graph, as evidenced by code statements that clearly contain direct function calls. This is pretty easy even with a "bad parser".
To get an upper bound on the call graph, you can do a conservative analysis of function pointers, which gets you around the halting problem with some obvious loss of precision. That's still a lot better than *just* the direct function calls.
> My objection is to its hype, not its functionality.
