Re: gsdoc version 1.0.0

[Richard Frith-Macdonald]

On Monday, October 21, 2002, at 09:22  pm, Chris B. Vetter wrote:

> On Tue, 15 Oct 2002 06:08:16 +0100
> Richard Frith-Macdonald <richard@brainstorm.co.uk> wrote:
> > I've modified NSProcessInfo so that manually supplying it with
> > argc,argv,envp overrides any values determined automatically,
> > and modified autogsdoc  to use this ... so if it works now, it
> > would tell us that the problem is with the mechanism NSProcessInfo
> > uses to determine the contents of argv on your system.
> > I also occurred to me that the problem might be with the kernel not
> > permitting large argument lists ... this seems unlikely ... but if
> > your make, or shell, or kernel is having a problem with this, let me
> > know  - I've added an option for autogsdoc to read the names of the
> > headers from a file, so such a problem can be worked round.
>
> autogsdoc in last Friday's checkout worked. No problems with creating
> the HTML files. Even referencing NS<classes> and Protocol documentation
> now works. Great.

Well, that demonstrates that NSProcessInfo is broken on your system.
Please can you let me know what software/os you are running and what the
configure script says about the mechanism NSProcessInfo should use to
determine the contents of argv ... if it fails for large numbers of
arguments in autogsdoc, it will also fail for all other applications.

> However, todays checkout, though HTML will still be created, will warn
> that, eg:
>
>   2002-10-21 13:10:00.605 autogsdoc[83991] Location of class 'NSMenu'
>   (referenced from MyObject) not found or not unique.

I guess the warning needs to be more specific.

> On a side-note, three thoughts:
>
> 1) If you reference a Class plus method, ala [NSApplication-run], a 
> space
>    should be added in HTML, [NSApplication -run]. It's easier to read.

Yep. will do.

> 2) The HTML link to any NS<class> is given as a full path - however, 
> the
>    web browser will 'expand' it to, eg:
>
>      
> /home/foo/GNUstep/Documentation/opt/GNUstep/System/Documentation/...
>
>    a <a href=file:/.... would do the trick.

I don't think I understand this comment ...
autogsdoc does not generate a 'file:' prefix in its links, because you 
might
be making the documentation available via http:
It produces relative paths for files in the current project, and 
absolute paths
where it is referencing files in other projects.  In the first case a 
browser
will 'expand' the relative path by prepending the path to the page in 
which the
link occurs, in the second it will use the absolute path as supplied.

Is there some bug in the browser you are using?