This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [GSoC 2015] Dynamic Documentation Project


Hi!

On Sun, 1 Feb 2015 08:53:13 +0530, Sajidur Rahman <sajidur1993@gmail.com> wrote:
> I am Sajidur, from India. Currently I am enrolled in Computer Science
> & Engineering branch at BITS Pilani University. I went through all the
> ideas mentioned in the GNU's GSoC ideas page and found the dynamic
> documentation idea under glibc, fit for my skills as well as interest.

For reference, that's from last year's Summer of Code projects for GNU,
glibc: <http://www.gnu.org/software/soc-projects/ideas-2014.html#glibc>.

It is not yet certain that the GNU project/glibc will again be
participating in the Google Summer of Code.  (But there is an intention
to again apply as a mentoring organization,
<https://lists.gnu.org/archive/html/summer-of-code/2015-01/msg00000.html>.)

> I have been thinking about the idea and reading materials relating to
> it since last few days and these are the points that I believe would
> constitute the project. Please correct me wherever I might have
> misunderstood.

Thanks for your interest in this project, and also thanks for contacting
us early!

> 1. The project is basically to develop a program which would read the
> internal inline markups in a C code and dynamically create a file,

I'm not the one who came up with this project idea (Carlos?
<https://sourceware.org/glibc/wiki/GSoC?action=diff&rev1=1&rev2=2>), but
I'd assume that the idea rather is to integrate one of the existing
programs for this task: DoxyGen, Sphinx, and so on?  (And then,
obviously, add the respective markup code to glibc's source code files.)

> which breaks down the source code file into its constituent classes,
> functions, structures etc and individually documents them, but under
> one common umbrella for the whole source code. The closest to such an
> implementation, what I could think of and that I have worked with,
> would be javadoc for Java. (please correct me if I am wrong)
> 
> 2. The second step is to integrate the created documentation to the
> existing texi documentation so as to maintain cohesion in
> documentation.
> 
> I think that the project requires a lot of text and pattern matching
> algorithms so that it correctly reads the markups and extracts the
> comments from the source file. Secondly, it requires the necessary
> prerequisites to make a texi file and add it to the 'monolithic'
> manual. I am well equipped with the former skill, which requires
> working with pattern matching algorithms as I have used such
> algorithms in a lot of codes that I have written. But the latter
> requirement (familiarity with texi format) is what I'll have to learn
> and practice for a comprehensive understanding.
> 
> I request you all to kindly correct me wherever I am wrong, and also
> comment if the way that I am going is the right path to doing it.


GrÃÃe,
 Thomas

Attachment: signature.asc
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]