Re: [suggestion] new target GTAGS.

[Shigio Yamaguchi]

> I'm not against doing this.  Since GTAGS is a GNU program, and one of
> automake's goals is to work well with other GNU programs, it seems
> like a reasonable idea.

I'm glad to hear that.
 
> I'm curious: what advantage does global give over etags or idutils?

Most important advantage is that GLOBAL can be used in various environments
like nvi, elvis, emacs, less and any web browsers.

Besides, GLOBAL
o can locate not only object definitions but also object references.
o locate also path which includes specified pattern.
o understand POSIX 1003.2 regular expressions.
o plugged-in parser is available to treat new language.
o support incremental updating of tag files.
o support customizing with global.conf.
o generate completion list for completing input method.

> >> GTAGS:
> >>gtags -i $(GTAGS_ARGS)
> 
> Note that this will be run in the build tree.
> 
> You indicate elsewhere that it should be run in the source tree.  But
> that is wrong for automake (there are some special exceptions, but
> this isn't one).
> 
> Does gtags have an option so that it can be run in one directory but
> put its output files in another?

Yes, it does.
The following command line makes tag files in /var/obj instead of current
directory.

% gtags /var/obj

But gtags must be invoked in the root of source directory. So if the current
directory is not the place then we must invoke like:

GTAGS:
(cd $(ROOT_OF_SRC_DIR); gtags -i /var/obj)

If the tag files does not exist at the root of source directory,
you can use the tag files like this:

% pwd
% /usr/src/usr.bin/ctags
% gtags /var/obj<- make tag files in /var/obj
% setenv GTAGSROOT `pwd`
% setenv GTAGSDBPATH /var/obj
% global -x main
main  83 ctags.cmain(argc, argv)

By the way, where does automake put tag files to?
If there are some conventions in automake then I would like to support it
in GLOBAL.
--
Shigio Yamaguchi - Tama Communications Corporation
Mail: [EMAIL PROTECTED], (Spare mail: [EMAIL PROTECTED])

Re: More fun with BUILT_SOURCES

[Tom Tromey]

> "Braden" == Braden McDaniel <[EMAIL PROTECTED]> writes:

Tom> I'd really like to find a better solution for the built files
Tom> problem.  This is currently too hard to do in automake.

Braden> I ended up doing this:
Braden>   $(libfoo_la_OBJECTS): mybuiltheader.h

I recently changed how BUILT_SOURCES work.  Now they are all built
before `all' is built.  I think this should fix the problems with
building headers before dependencies have ever been calculated.

Tom

Re: [suggestion] new target GTAGS.

[Tom Tromey]

> ">" == Shigio Yamaguchi <[EMAIL PROTECTED]> writes:

>> How about adding new target 'GTAGS' that means GLOBAL's tag to
>> automake?

I'm not against doing this.  Since GTAGS is a GNU program, and one of
automake's goals is to work well with other GNU programs, it seems
like a reasonable idea.

>> GNU GLOBAL  is a
>> source code tag system that works the same way across diverse
>> environments. It supports C, C++, Yacc and Java source code.

I'm curious: what advantage does global give over etags or idutils?

>> GTAGS:
>>  gtags -i $(GTAGS_ARGS)

Note that this will be run in the build tree.

You indicate elsewhere that it should be run in the source tree.  But
that is wrong for automake (there are some special exceptions, but
this isn't one).

Does gtags have an option so that it can be run in one directory but
put its output files in another?

Tom

Re: [PATCH] Repair path of VTEXI with non gnu-makes

[Tom Tromey]

> "Marc" == Marc Espie <[EMAIL PROTECTED]> writes:

Marc> 2000-12-15Marc Espie <[EMAIL PROTECTED]>
Marc>   * automake.in (handle_texinfo): Make path of $vtexi explicit in
Marc>   dependency.
Marc>   * texi-vers.am: Likewise.

This seems ok.  I checked it in.

Tom

Re: *-local targets

[Tom Tromey]

> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:

Derek> Is there some reason that *-local targets aren't always valid
Derek> when their parent exists?  I wanted to define
Derek> distclean-hdr-local to remove options.h-SAVED as well as
Derek> options.h, but I can't seem to get it to work.

I'm reluctant to implement this because many of the targets automake
generates are implementation details.  If I had thought ahead (back in
'96, say), I would have been more careful about reserving a namespace
so that internal targets would be more obviously private.

For instance, `distclean-hdr' is an implementation detail.  You can't
really rely on its name staying the same from release to release.

All you really can rely on are the targets we publicize, like `all'.

Tom

Re: problem compiling on DEC with dependencies (cxx -M)

[Tom Tromey]

> "Patrick" == Patrick Guio <[EMAIL PROTECTED]> writes:

Patrick> I am not sure if this is to be adressed to libtool or maybe
Patrick> automake since the problem might come from depcom...  Anyway
Patrick> I am trying to build a c++ library using libtool on a
Patrick> alphaev6-dec-osf5.0 using cxx.

Did you ever get a response to this?

Patrick> source='parser.cpp' object='libutilities_la-parser.lo' libtool=yes \
Patrick> depfile='.deps/libutilities_la-parser.Plo'
Patrick> tmpdepfile='.deps/libutilities_la-parser.TPlo' \
Patrick> depmode=dashmstdout /bin/ksh ../depcomp \
Patrick> [ ... ]

Patrick> The problem is that when specifying -M with cxx even though
Patrick> you put also the options -c -o $obj you don't create the .o
Patrick> file.  And it looks like that the .o is removed first and
Patrick> then the cxx -M is run without running again cxx alone,
Patrick> therefore the .o is not created.

I imagine this is a bug in depcomp and not in libtool.  depcomp is
responsible for invoking the compiler twice -- once with `-M' and once
without.

However when I look at the `dashmstdout' case in depcomp, it looks
like it does the right thing to me.

Could you try your hand at debugging it?

Tom

Re: Automake suffixes ordering [patch]

[Tom Tromey]

> "Kevin" == Kevin Ryde <[EMAIL PROTECTED]> writes:

Kevin> I'd like to propose the patch below to put any $(SUFFIXES) from
Kevin> Makefile.am at the head of the .SUFFIXES list in Makefile.in.

Thanks, I finally checked this in.

Tom

Re: ./configure & .deps directory

[Tom Tromey]

> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:

Derek> Is there a good reason the configure script creates
Derek> $(top_builddir)/.deps during the test that sets $DEPDIR and
Derek> doesn't delete it again?  Besides some developer or other
Derek> needing sleep?  ;)

Derek> My distribution certainly doesn't seem to need that directory
Derek> sitting around...


This directory is needed by the dependency tracking implementation.

I agree though that this macro is mysterious.  Why doesn't it create
`_deps' if that is what is chosen?

Tom

Re: BOUNCE pdftex@tug.org: Non-member submission from ["Derek R. Price" ]

[Derek R. Price]

Raja R Harinath wrote:

> > directory from the same source files, this would disable either the building
> > of PDFs or it would disable everything else.
>
> Actually, new versions of texinfo.tex from ftp.gnu.org seem to not
> need a special pdftexinfo.tex.

Yep.  That seems to have done the trick as far as I'm concerned. 
*.info, *.ps,
and *.pdf all build and pass cursory inspection, anyhow.

Of course, now my users can miss upgrades to the distributed version of
texinfo.tex and possibly useful changes in their tex distribution's
operation,
but I guess I can confine that argument to the Automake folks and
Richard
Stallman for awhile.  :)

Derek

--
Derek Price  CVS Solutions Architect (
http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
All work and no play makes Bart a dull boy.
All work and no play makes Bart a dull boy.
All work and no play makes Bart a dull boy...

  - Bart Simpson on chalkboard, _The Simpsons_