I would recommend you work on v2.1 and not v1.1.
It will not be long before v2 series becomes the primary focus for all
of us.
As for tools well I have used doxygen in the past but I must admit it
issues too much info much of which I find un-needed.
I just write comments on my copy of the code but there again I have
not had to look at the whole codebase only small segments.
One project that I do wish to get involved in is to migrate the
compiler to IBM MVS but I need to see if anyone else is involved doing
so already.
This will not be easy although it does have a gcc compiler but v3.4
and a earlier one around v3.3 along with the 'C' libraries. These are
the last versions with support for the IBM mainframe architecture.
Vince
On 29/04/14 14:07, Patrick wrote:
Hi Everyone
Thanks again to Brian for yet another very helpful post and I am
thankful for the private messages I received too.
I think I am going to make another big push to learn the code base.
I printed all the source code from 1.1. I think this is okay for bulk
memorization but I wouldn't do it again,
I ran cobc through cflow last night. It gives results like this:
main() <int main (int argc, char **argv) at cobc.c:3669>:
memset()
cobc_sig_handler() <void COB_A_NORETURN cobc_sig_handler (int sig)
at cobc.c:1478>:
raise()
kill()
getpid()
exit()
continues on....
It shows that raise, kill, getpid etc are callable from cobc_sig_handler
but it can't tell which path of execution it will take.
I was thinking of building a version with a whole bunch of printf
statements inside each function that would print the path of execution,
"I am raise()" etc.
I thought that I would then look at each function and then use ctags to
view the argument definitions.
Does this sound like a logical way to study the code base ? If not could
you recommend some other techniques ?