Re: BSD Make
> "Larry" == Larry Jones <[EMAIL PROTECTED]> writes: Larry> It works save for one bug: Grr. Thanks for testing this. Tom
Re: 82-lang-finish.patch
> "Akim" == akim <[EMAIL PROTECTED]> writes: >> How hard is it going to be to move from the current object >> implementation to the one we really want? Akim> You want me to read in dead animals bodies :) Well, dead vegetables anyway. Akim> In short, reifying automake, I don't know. Reifying languages, Akim> macros and rules, yes! definitely! Really I was just asking a syntactical question. But I looked around at some of my own Perl code that uses the object system, and I think I answered my own question. Basically I wanted to know if the 82- patch and other Language patches were evolutionarily forward steps or steps into a dead end. And now I think they are the former. So this patch is ok. Tom
Re: 88-file-contents-include.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> * automake.in (@conditional_stack): Rename as... Akim> (@cond_stack): this. Akim> (&file_contents_internal): Support inclusion of files. This patch is ripe for justification. I assume this is just another precursor to merging the two file readers? Anyway, this patch is fine. I just don't understand why we want it. Tom
Re: 86-lang-lang.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> * automake.in (&finish_languages, &handle_single_transform_list) Akim> (&add_depend2, &handle_dependencies): No longer use the language Akim> name in `$lang'. Rename `$lang_obj' as `$lang'. Ok. Tom
Re: 84-lang-output_arg.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> * automake.in (®ister_language): Rename `output-arg' as Akim> `output_arg' to match the Language attribute. Akim> Set the defaults in %options instead of $lang. This should say `%option', not `%options'. This is ok. Tom
Re: 85-lang-new-hash.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> The patch is really a proposal: it relies on a modified version of Akim> Perl 5.6's Class::Struct. The modification are minimal, and just Akim> ensure that it works with 5.005: I like this but we can't use it until the licensing is worked out. Keeping this ugly is not a big burden. Tom
Re: 83-lang-name.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> * automake.in (Language): Add attribute `name. Akim> (®ister_language): The name of the language is now given in the Akim> hash. Akim> No longer use `$lang' as the name of the language. Akim> Rename `$lang_obj' as `$lang'. Ok Tom
Re: 90-header-include-data.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> * automake.in (&am_install_var): Transform `ONE_PRIMARY'. Akim> * data.am: Use it. Akim> * header.am: Include data.am. Ok. All is clear now, thanks. Tom
Re: 87-lang-extenions.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> * automake.in (&lang_extensions): Remove. Akim> (&add_depend2, &saw_sources_p): Adjust. Akim> * depend2.am: `%EXT%' no longer includes the dot. Ok. Tom
Re: 91-handle-java-python-lisp.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&handle_emacs_lisp): Be like &handle_python, i.e.,
Akim> return if there are no files, hook elist-comp on the Autoconf
Akim> macro, rely on lisp.am to define variables.
Akim> (&handle_python, &handle_java): Likewise.
Akim> (&scan_one_autoconf_file): Pseudo AC_SUBST of `pythondir' and
Akim> `PYTHON' must be handled here, not in `&handle_python'.
Akim> * java.am: Define needed variables and rules.
This patch changes the java handling.
The old definitions:
Akim> -&define_variable ('JAVAC', 'javac');
Akim> -&define_variable ('JAVACFLAGS', '');
The new ones:
Akim> +JAVAC = @JAVAC@
Akim> +JAVACFLAGS = @JAVACFLAGS@
These shouldn't change.
Otherwise the patch is fine.
Tom
Re: 89-transform-primary.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> * automake.in (&am_install_var): Transform `PRIMARY'. Akim> * data.am: Equip with %PRIMARY%. Ok. I assume this is working up to something? Tom
Re: 97-am-init-automake.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> * automake.in ($seen_make_set, $seen_prog_install) Akim> ($seen_arg_prog): Remove. Akim> (&handle_programs, &handle_scripts, &scan_one_autoconf_file): Akim> Remove related code. Ok. Tom
Re: 96-ac-path-xtra.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> * automake.in ($seen_path_xtra): Remove. Akim> (&handle_compile): Don't handle `AC_PATH_XTRA' AC_SUBST variables. Akim> (&scan_one_autoconf_file): Do it, instead of setting $seen_path_xtra. Ok. Tom
Re: 95-libs-var-am.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> * automake.in (&read_am_file, &file_contents_internal): Don't Akim> define macros when `FALSE', to avoid errors on doubly defined Akim> variables but under condition `FALSE'. In order to allow... Akim> (&am_install_var): When reading the associated file for the first Akim> time, enable `%?FIRST%'. Akim> (&handle_libraries): Let libs.am define $(AR) and $(RANLIB). Akim> * libs.am: Do it when `%?FIRST%'. This is ok. However I wonder if it is really what we want. This is an ad hoc mechanism in am_install_var. But we'll also need an ad hoc mechanism in add_depend2. Why not introduce a syntax for defining something once? *FOO = ... We would interpret this after all other substitutions are applied to the line. That would make it useful for depend2.am. At some point we should document the syntax of the .am files. It doesn't have to be anything formal; just a comment in automake.in. Tom
Re: 94-ansi2knr.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> * automake.in (handle_compile): Let ansi2knr.am define $(ANSI2KNR). Akim> * ansi2knr.am: Do it. Akim> Prefer `if %?FOO% to `if %!FOO%. Ok. Please be aware that the ansi2knr code is fairly fragile. We've had a lot of bugs here in the past. Extra care is required, especially since it isn't actually tested very frequently. Tom
Re: 92-lang-pure.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> * automake.in (®ister_language, &finish_languages): Use `pure' Akim> as a Boolean. Akim> (®ister_language): Use %done properly with objects, not names. Akim> (&finish_languages): Replace `$non_c' with `$needs_c'. Ok. Tom
Re: 93-robert-fix.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> * program.am: Fix a stupid typo: now *all* (not none) the programs Akim> use `$(EXEEXT)'. Akim> Reported by Robert Boehne. This already went in so I'm not looking at it. I presume it was an obvious bug fix. Tom
Re: BSD Make
Tom Tromey writes: > > Can you test the appended patch? If it works I will check it in. I > don't have access to a BSD `make' to try it. It works save for one bug: > Index: m4/make.m4 [...] > @@ -11,14 +10,27 @@ > # If we don't find an include directive, just comment out the code. > AC_MSG_CHECKING([for style of include used by $am_make]) > _am_include='#' > -for am_inc in include .include; do Here you delete the do... > - echo "$am_inc confinc" > confmf > +_am_quote= > +_am_result=none > +# First try GNU make style include. > +echo "include confinc" > confmf > +if test "`$am_make -s -f confmf 2> /dev/null`" = "done"; then > + _am_include=include > + _am_quote= > + _am_result=GNU > +fi > +# Now try BSD make style include. > +if test "$_am_include" = "#"; then > + echo '.include "confinc"' > confmf > if test "`$am_make -s -f confmf 2> /dev/null`" = "done"; then > - _am_include=$am_inc > - break > + _am_include=.include > + _am_quote='"' > + _am_result=BSD > fi > +fi > done ... but here you neglected to delete the matching done. After correcting that, it works fine with BSD make and with GNU make. -Larry Jones Yep, we'd probably be dead by now if it wasn't for Twinkies. -- Calvin
Re: 82-lang-finish.patch
On Thu, Apr 12, 2001 at 12:21:12AM +0200, [EMAIL PROTECTED] wrote: > On Wed, Apr 11, 2001 at 03:10:07PM -0600, Tom Tromey wrote: > > > > How hard is it going to be to move from the current object > > implementation to the one we really want? > > In short, reifying automake, I don't know. Reifying languages, macros > and rules, yes! definitely! Hm, lemme guess: I was completely out of topic, and the question was about languages, and languages only... Technically, inheritance with Class::Struct is fine. But (and this is part of my previous answer) if you mean ``how long is it going to take to be some structure without circular dependency'', I still have no idea today. I can see layers arise, but still circular layers :)
Re: 82-lang-finish.patch
On Wed, Apr 11, 2001 at 03:10:07PM -0600, Tom Tromey wrote: > > How hard is it going to be to move from the current object > implementation to the one we really want? You want me to read in dead animals bodies :) I currently have no idea... I'm sure macros and rules should be objects, afterwards, I don't know. Currently, by far, the handling of macros is superior to that of rules, but there is still one big bad thing: macros are split accross various hashes, instead of a single hash of macro objects. This should be very easy to reify. I wanted to find some common interface for macros and rules, given that they both share the conditional main root, but I'm not sure it is the right way. Now, for the core Automake, I just don't know. Another fundamental guideline I try to follow is that the knowledge should be in *.am files only, not automake. Some projections in the future (the 1?? patches being some signs of this future) I imagine seem to show there is some contradiction between the two approaches. In short, reifying automake, I don't know. Reifying languages, macros and rules, yes! definitely!
Re: BSD Make
Tom Tromey writes: > > > "Derek" == Derek R Price <[EMAIL PROTECTED]> writes: > > Derek> A new bug report on the BSD make's include syntax... sounds > Derek> like we're pretty close. > > Can you test the appended patch? If it works I will check it in. I > don't have access to a BSD `make' to try it. I'll test it tonight and let you know how it looks. -Larry Jones Start tying the sheets together. We'll go out the window. -- Calvin
Re: BSD Make
> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
Derek> A new bug report on the BSD make's include syntax... sounds
Derek> like we're pretty close.
Can you test the appended patch? If it works I will check it in. I
don't have access to a BSD `make' to try it.
2001-04-11 Tom Tromey <[EMAIL PROTECTED]>
* automake.in (handle_dependencies): Add `@_am_quote@' where
appropriate.
* m4/make.m4 (AM_MAKE_INCLUDE): Handle BSD-style make.
Tom
Index: automake.in
===
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision 1.1034
diff -u -r1.1034 automake.in
--- automake.in 2001/04/10 09:20:59 1.1034
+++ automake.in 2001/04/11 21:18:52
@@ -3108,7 +3108,8 @@
$output_rules .= "\n";
foreach my $iter (@deplist)
{
- $output_rules .= '@AMDEP_TRUE@@_am_include@ ' . $iter . "\n";
+ $output_rules .= ('@AMDEP_TRUE@@_am_include@ @_am_quote@'
+ . $iter . '@_am_quote@' . "\n");
}
$output_rules .= &file_contents ('depend');
Index: m4/make.m4
===
RCS file: /cvs/automake/automake/m4/make.m4,v
retrieving revision 1.4
diff -u -r1.4 make.m4
--- make.m4 2001/04/11 04:17:21 1.4
+++ make.m4 2001/04/11 21:18:52
@@ -3,7 +3,6 @@
# Check to see how make treats includes.
AC_DEFUN([AM_MAKE_INCLUDE],
[am_make=${MAKE-make}
-# BSD make uses .include
cat > confinc << 'END'
doit:
@echo done
@@ -11,14 +10,27 @@
# If we don't find an include directive, just comment out the code.
AC_MSG_CHECKING([for style of include used by $am_make])
_am_include='#'
-for am_inc in include .include; do
- echo "$am_inc confinc" > confmf
+_am_quote=
+_am_result=none
+# First try GNU make style include.
+echo "include confinc" > confmf
+if test "`$am_make -s -f confmf 2> /dev/null`" = "done"; then
+ _am_include=include
+ _am_quote=
+ _am_result=GNU
+fi
+# Now try BSD make style include.
+if test "$_am_include" = "#"; then
+ echo '.include "confinc"' > confmf
if test "`$am_make -s -f confmf 2> /dev/null`" = "done"; then
- _am_include=$am_inc
- break
+ _am_include=.include
+ _am_quote='"'
+ _am_result=BSD
fi
+fi
done
AC_SUBST(_am_include)
-AC_MSG_RESULT($_am_include)
+AC_SUBST(_am_quote)
+AC_MSG_RESULT($_am_result)
rm -f confinc confmf
])
Re: 82-lang-finish.patch
Akim> I do share your dislike for the structure, but please, note that Akim> we are defining methods per _object_. Cleaner would mean one Akim> *class* per language, which seems overkill to me. Tom> Really? Why? To me it seems natural. Akim> Yes, you are right. But we still have to face the circular Akim> dependency thingy. I don't think Automake is ready for this. Ok. How hard is it going to be to move from the current object implementation to the one we really want? Is it simply a matter of rewriting into classes and then making a factory to generate the objects for us? That is, no changes in the code that manipulates the objects themselves? If that is the case then I'm more comfortable with the current approach, since it will flow into the solution we want with relative ease. Tom
Re: depcomp w/ libtool leaves %% in Makefile.in
Ignore this, my email server is just very slow. Robert Robert Boehne wrote: > > Akim Demaille wrote: > > > > Please, edit depend2.am and replace > > > > if %?LIBTOOL?% > > > > endif %?LIBTOOL?% > > > > with > > > > if %?LIBTOOL% > > > > endif %?LIBTOOL% > > > > (no ? at the end). It should make it, right? > > That fixed it! I've attached a patch. > > Thanks Akim! > > -- > Robert Boehne Software Engineer > Ricardo Software Chicago Technical Center > TEL: (630)789-0003 x. 238 > FAX: (630)789-0127 > email: [EMAIL PROTECTED] > > > ChangeLog entry: > > 2001-04-11 Robert Boehne <[EMAIL PROTECTED]> > > * depend2.am: Changed %?LIBTOOL?% to %?LIBTOOL% > in libtool object file rule. > > Index: depend2.am > === > RCS file: /cvs/automake/automake/depend2.am,v > retrieving revision 1.34 > diff -u -r1.34 depend2.am > --- depend2.am 2001/04/09 14:50:47 1.34 > +++ depend2.am 2001/04/11 17:32:56 > @@ -37,7 +37,7 @@ > endif %AMDEP% > %COMPILE% -c -o %OBJ% `test -f %SOURCE% || echo '$(srcdir)/'`%SOURCE% > > -if %?LIBTOOL?% > +if %?LIBTOOL% > ?GENERIC?%EXT%.lo: > ?!GENERIC?%LTOBJ%: %SOURCE% > if %AMDEP% > @@ -46,7 +46,7 @@ > $(%FPFX%DEPMODE) $(depcomp) @AMDEPBACKSLASH@ > endif %AMDEP% > %LTCOMPILE% -c -o %LTOBJ% `test -f %SOURCE% || echo '$(srcdir)/'`%SOURCE% > -endif %?LIBTOOL?% > +endif %?LIBTOOL% > > ?GENERIC?%EXT%.obj: > ?!GENERIC?%OBJOBJ%: %SOURCE% -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: [EMAIL PROTECTED]
Re: depcomp w/ libtool leaves %% in Makefile.in
Akim Demaille wrote: > > Please, edit depend2.am and replace > > if %?LIBTOOL?% > > endif %?LIBTOOL?% > > with > > if %?LIBTOOL% > > endif %?LIBTOOL% > > (no ? at the end). It should make it, right? That fixed it! I've attached a patch. Thanks Akim! -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: [EMAIL PROTECTED] ChangeLog entry: 2001-04-11 Robert Boehne <[EMAIL PROTECTED]> * depend2.am: Changed %?LIBTOOL?% to %?LIBTOOL% in libtool object file rule. Index: depend2.am === RCS file: /cvs/automake/automake/depend2.am,v retrieving revision 1.34 diff -u -r1.34 depend2.am --- depend2.am 2001/04/09 14:50:47 1.34 +++ depend2.am 2001/04/11 17:32:56 @@ -37,7 +37,7 @@ endif %AMDEP% %COMPILE% -c -o %OBJ% `test -f %SOURCE% || echo '$(srcdir)/'`%SOURCE% -if %?LIBTOOL?% +if %?LIBTOOL% ?GENERIC?%EXT%.lo: ?!GENERIC?%LTOBJ%: %SOURCE% if %AMDEP% @@ -46,7 +46,7 @@ $(%FPFX%DEPMODE) $(depcomp) @AMDEPBACKSLASH@ endif %AMDEP% %LTCOMPILE% -c -o %LTOBJ% `test -f %SOURCE% || echo '$(srcdir)/'`%SOURCE% -endif %?LIBTOOL?% +endif %?LIBTOOL% ?GENERIC?%EXT%.obj: ?!GENERIC?%OBJOBJ%: %SOURCE%
FYI: depend2
Index: ChangeLog from Akim Demaille <[EMAIL PROTECTED]> * depend2.am: Fix the `if' condition for Libtool. Reported by Robert Boehne. Index: depend2.am === RCS file: /cvs/automake/automake/depend2.am,v retrieving revision 1.34 diff -u -u -r1.34 depend2.am --- depend2.am 2001/04/09 14:50:47 1.34 +++ depend2.am 2001/04/11 17:28:17 @@ -37,7 +37,7 @@ endif %AMDEP% %COMPILE% -c -o %OBJ% `test -f %SOURCE% || echo '$(srcdir)/'`%SOURCE% -if %?LIBTOOL?% +if %?LIBTOOL% ?GENERIC?%EXT%.lo: ?!GENERIC?%LTOBJ%: %SOURCE% if %AMDEP% @@ -46,7 +46,7 @@ $(%FPFX%DEPMODE) $(depcomp) @AMDEPBACKSLASH@ endif %AMDEP% %LTCOMPILE% -c -o %LTOBJ% `test -f %SOURCE% || echo '$(srcdir)/'`%SOURCE% -endif %?LIBTOOL?% +endif %?LIBTOOL% ?GENERIC?%EXT%.obj: ?!GENERIC?%OBJOBJ%: %SOURCE%
Re: depcomp w/ libtool leaves %% in Makefile.in
Please, edit depend2.am and replace if %?LIBTOOL?% endif %?LIBTOOL?% with if %?LIBTOOL% endif %?LIBTOOL% (no ? at the end). It should make it, right?
depcomp w/ libtool leaves %% in Makefile.in
Here is a snippet of one of my Makefile.in's in a subdirectory of a project using CVS MLB Libtool and dependencies. This was generated with CVS Automake (as of today) with --include-deps on the command line. The problem is that the "if %%" line isn't translated into anything by configure. I don't understand how this is supposed to work but I'm sure Akim knows. Thanks, Robert .c.o: source='$<' object='$@' libtool=no @AMDEPBACKSLASH@ depfile='$(DEPDIR)/$*.Po' tmpdepfile='$(DEPDIR)/$*.TPo' @AMDEPBACKSLASH@ $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@ $(COMPILE) -c -o $@ `test -f $< || echo '$(srcdir)/'`$< if %% .c.lo: source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@ depfile='$(DEPDIR)/$*.Plo' tmpdepfile='$(DEPDIR)/$*.TPlo' @AMDEPBACKSLASH@ $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@ $(LTCOMPILE) -c -o $@ `test -f $< || echo '$(srcdir)/'`$< endif %% . -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: [EMAIL PROTECTED]
Re: Default postscript cleans miss *.cps & *.fns.
| cvs.texinfo:@deffn Command {cvs add} [@code{-k} kflag] [@code{-m}
| message] files @dots{}
| cvs.texinfo:@end deffn
| cvs.texinfo:@deffn Command {cvs remove} [options] files @dots{}
| cvs.texinfo:@end deffn
| cvs.texinfo:@deffn Command {cvs annotate} [@code{-flR}] [@code{-r
| rev}|@code{-D date}] files @dots{}
| cvs.texinfo:@end deffn
| cvs.texinfo:@deffn Command {cvs watch on} [@code{-lR}] files
| @dots{}
| cvs.texinfo:@end deffn
| cvs.texinfo:@deffn Command {cvs watch off} [@code{-lR}] files
| @dots{}
| cvs.texinfo:@end deffn
| cvs.texinfo:@deffn Command {cvs watch add} [@code{-a} action]
| [@code{-lR}] files @dots{}
| cvs.texinfo:@end deffn
| cvs.texinfo:@deffn Command {cvs watch remove} [@code{-a} action]
| [@code{-lR}] files @dots{}
| cvs.texinfo:@end deffn
| cvs.texinfo:@deffn Command {cvs edit} [options] files @dots{}
| cvs.texinfo:@end deffn
| cvs.texinfo:@deffn Command {cvs unedit} [@code{-lR}] files @dots{}
| cvs.texinfo:@end deffn
| cvs.texinfo:@deffn Command {cvs watchers} [@code{-lR}] files
| @dots{}
| cvs.texinfo:@end deffn
| cvs.texinfo:@deffn Command {cvs editors} [@code{-lR}] files @dots{}
|
| cvs.texinfo:@end deffn
|
| Which is the same order the entries appear in cvs.fns. Glancing at the
| texinfo manual reveals that `Command' is a category argument and not
| literal. Will that do the trick?
In fact it was my understanding that what you describe explains why
you have some content in .fn, not .fns. To get .fns, you need to use
the index somewhere.
Is there a command index somewhere? How is it created in the Texinfo file?
depcomp not found if in aux_dir
Hello:
I'm testing the CVS MLB Libtool with current CVS Automake and Autoconf.
I've found that dependency tracking doesn't work because the depcomp
script is copied into the auxiliary directory specified with
AC_CONFIG_AUX_DIR('directory') as it should, but when the generated
configure script is run for that project, the depcomp script is only
found if it is $(top_srcdir)/depcomp.
I don't know the first thing about perl or I would have sent in a patch,
sorry!
Here is sample output from 'configure':
checking how to run the C++ preprocessor... g++ -E
checking dependency style of g++... cp: /icarus/OCC/OCC/depcomp: No such
file or directory
/icarus/OCC/OCC/configure: ./depcomp: No such file or directory
none
--
Robert Boehne Software Engineer
Ricardo Software Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email: [EMAIL PROTECTED]
Re: Default postscript cleans miss *.cps & *.fns.
Akim Demaille wrote:
> elsif (/^\@syncodeindex \w+ (\w*)/
> || /^\@printindex (\w+)/)
> {
> push @clean_suffixes, "$1s";
> }
Yep. That works.
> IIRC, you also had problems with fns. What does a `grep fn *texi*' gives?
Not much obviously useful, but you prompted me to look in the cvs.fns file.
Except for the first line, lines are of the form:
\entry {\code {command}}{index}
Where command is variable and index is a number. Using `fgrep -w "command"
*.texi*' reveals that each command has a corresponding texinfo command like
the following in the manual:
@deffn Command {command} ...
where `Command' (with a capital 'C') is a literal and ... varies. `fgrep -w
deffn' reveals:
cvs.texinfo:@deffn Command {cvs add} [@code{-k} kflag] [@code{-m}
message] files @dots{}
cvs.texinfo:@end deffn
cvs.texinfo:@deffn Command {cvs remove} [options] files @dots{}
cvs.texinfo:@end deffn
cvs.texinfo:@deffn Command {cvs annotate} [@code{-flR}] [@code{-r
rev}|@code{-D date}] files @dots{}
cvs.texinfo:@end deffn
cvs.texinfo:@deffn Command {cvs watch on} [@code{-lR}] files
@dots{}
cvs.texinfo:@end deffn
cvs.texinfo:@deffn Command {cvs watch off} [@code{-lR}] files
@dots{}
cvs.texinfo:@end deffn
cvs.texinfo:@deffn Command {cvs watch add} [@code{-a} action]
[@code{-lR}] files @dots{}
cvs.texinfo:@end deffn
cvs.texinfo:@deffn Command {cvs watch remove} [@code{-a} action]
[@code{-lR}] files @dots{}
cvs.texinfo:@end deffn
cvs.texinfo:@deffn Command {cvs edit} [options] files @dots{}
cvs.texinfo:@end deffn
cvs.texinfo:@deffn Command {cvs unedit} [@code{-lR}] files @dots{}
cvs.texinfo:@end deffn
cvs.texinfo:@deffn Command {cvs watchers} [@code{-lR}] files
@dots{}
cvs.texinfo:@end deffn
cvs.texinfo:@deffn Command {cvs editors} [@code{-lR}] files @dots{}
cvs.texinfo:@end deffn
Which is the same order the entries appear in cvs.fns. Glancing at the
texinfo manual reveals that `Command' is a category argument and not
literal. Will that do the trick?
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net )
--
It is as useless to argue with those who have renounced the use and authority
of reason as to administer medication to the dead.
- Thomas Jefferson
Re: problem: unitialized +=
> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes:
Robert> 3) src/Makefile.am: cf_gen_DEPENDENCIES must be set with `='
Robert> before using `+='
>> We recently talked about this with Tom, and we agreed that there is
>> no reason not to do that (but to protect the user from herself, but
>> it's not our job). So consider this is solved. I don't have time
>> now, but I'll submit a patch soon.
Robert> The same applies to CFLAGS. In fact for CFLAGS it's probably
Robert> more important - you want to add to the configured CFLAGS
Robert> variable, not replace it. No rush for me though :].
Hm, I don't understand this sentence too well. CFLAGS should be
initialized, so you should not face this problem.
Could you give a try to Automake without the following else branch?
Just remove the - lines below from macro_define:
# An Automake variable must be consistently defined with the same
# sign by Automake. A user variable must be set by either `=' or
# `:=', and later promoted to `+='.
if ($var_is_am)
{
if (defined $var_type{$var} && $var_type{$var} ne $type)
{
am_line_error ($var,
("$var was set with `$var_type{$var}=' "
. "and is now set with `$type='"));
}
}
- else
- {
- if (!defined $var_type{$var} && $type eq '+')
- {
- am_line_error ($var, "$var must be set with `=' before using `+='");
- }
- }
$var_type{$var} = $type;
Re: problem: multiple definitions
> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes:
Robert> 2) snmplib/Makefile.am:14: DEFS multiply defined in condition
Robert> TRUE DEFS (User, where = 14) = {
>>
Robert> TRUE => -DSQUID_SNMP=1 }
>> Hm... I'll look into this one. The idea is that somehow we must
>> be able to tell Automake `look, this is an Automake variable, but
>> the user is allowed to override it'. Currently it's probably too
>> strict.
Robert> Any extra details needed - let me know.
I think that what I said does not apply, and does match with the
actual error you face. Could you grep for DEFS in your Makefile.am?
Thanks!
Re: Default postscript cleans miss *.cps & *.fns.
> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
Derek> Akim Demaille wrote:
>> > "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
>>
>> > "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> elsif (/^\@(syncode|print)index \w+ (\w*)/) { push
Akim> @clean_suffixes, "$1s";
>>
Tom> Shouldn't that be "$2s" here?
>> Yes, definitely. Thanks!
Derek> Neither one worked. I grepped for "@(syncode|print)index" in
Derek> CVS's texinfo source and got the following:
Derek> @printindex cp
Derek> Are the two \w segments above a typo or maybe just not the
Derek> general case?
Arg, sorry, I wrote this way too hastily. Try this:
elsif (/^\@syncodeindex \w+ (\w*)/
|| /^\@printindex (\w+)/)
{
push @clean_suffixes, "$1s";
}
IIRC, you also had problems with fns. What does a `grep fn *texi*' gives?
RE: problem with conditionals and \ separator in SOURCES
> You're right: line endings are to blame... the funny thing is that I got > the sources from a Linux CVS server, and the uncorrect line endings seem > to have been added during the dowloading... (actually I used WinCVS, so > this is quite likely). If you're using WinCVS and working with Unix/Linux-based repositories, I'd recommend checking the 'Use Unix line endings (0xa)' option in the preferences; this preserves Unix-style text on the client side. Make sure you're not using a DOSsy editor that converts them back to CRLF or inserts CRLF on edited lines though. You'll also have to do a nex checkout, as enabling this option also uses binary mode for CVS' administrative files. If you're using the command-line cvs that comes with WinCVS, use its --lf option (I have it set in my .cvsrc for convenience). > I didn't understand this last point: what should I check? What is cvs > automake? The current development version of Automake (which is available through CVS).
Re: Default postscript cleans miss *.cps & *.fns.
Akim Demaille wrote:
> > "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
>
> > "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
> Akim> elsif (/^\@(syncode|print)index \w+ (\w*)/) { push
> Akim> @clean_suffixes, "$1s";
>
> Tom> Shouldn't that be "$2s" here?
>
> Yes, definitely. Thanks!
Neither one worked. I grepped for "@(syncode|print)index" in CVS's
texinfo source and got the following:
@printindex cp
Are the two \w segments above a typo or maybe just not the general case?
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net )
--
It'll take a miracle to get you out of Casablanca and the Germans have outlawed
miracles.
- Sydney Greenstreet as Senor Ferrari, _Casablanca_
Re: problem: uninstall-am in makefile with no install targets and non-GNU make.
- Original Message -
From: "Akim Demaille" <[EMAIL PROTECTED]>
To: "Robert Collins" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, April 11, 2001 9:34 PM
Subject: Re: problem: uninstall-am in makefile with no install targets
and non-GNU make.
> > "Robert" == Robert Collins <[EMAIL PROTECTED]>
writes:
>
> Robert> Thanks Akim, adding that line should fix the make uninstall
> Robert> problem. However the makefile.in's created by automake are
> Robert> now corrupt: I get 1001 errors (I CVS updated first).
>
> Robert> The errors I get are (single samples of each) 1) AMDEP does
> Robert> not appear in AM_CONDITIONAL
>
> Run aclocal first.
Thanks. Done and it works. (I should have tried ... doh!)
> Robert> 2) snmplib/Makefile.am:14: DEFS multiply defined in condition
> Robert> TRUE DEFS (User, where = 14) = {
>
> Robert> TRUE => -DSQUID_SNMP=1 }
>
> Hm... I'll look into this one. The idea is that somehow we must be
> able to tell Automake `look, this is an Automake variable, but the
> user is allowed to override it'. Currently it's probably too strict.
Any extra details needed - let me know.
> Synthesizing the permissions is quite difficult :(
>
> Robert> 3) src/Makefile.am: cf_gen_DEPENDENCIES must be set with `='
> Robert> before using `+='
>
> We recently talked about this with Tom, and we agreed that there is no
> reason not to do that (but to protect the user from herself, but it's
> not our job). So consider this is solved. I don't have time now, but
> I'll submit a patch soon.
The same applies to CFLAGS. In fact for CFLAGS it's probably more
important - you want to add to the configured CFLAGS variable, not
replace it. No rush for me though :].
> For the time being, I suspect you should just not use the HEAD
Automake.
>
Unfortuneatly, being a cygwin user, I don't have too much choice. As
soon as I have a working automake, I'll be noteing the date, and
referring project members to that revision. (CVS is a wonderful thing).
I'll possibly take a snapshot and put that on the developers webpage
until the next stable automake release is made with these changes.
And in the meantime, you get lots of bleeding edge bug reports :]
Rob
Re: problem: uninstall-am in makefile with no install targets and non-GNU make.
> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes:
Robert> Thanks Akim, adding that line should fix the make uninstall
Robert> problem. However the makefile.in's created by automake are
Robert> now corrupt: I get 1001 errors (I CVS updated first).
Robert> The errors I get are (single samples of each) 1) AMDEP does
Robert> not appear in AM_CONDITIONAL
Run aclocal first.
Robert> 2) snmplib/Makefile.am:14: DEFS multiply defined in condition
Robert> TRUE DEFS (User, where = 14) = {
Robert> TRUE => -DSQUID_SNMP=1 }
Hm... I'll look into this one. The idea is that somehow we must be
able to tell Automake `look, this is an Automake variable, but the
user is allowed to override it'. Currently it's probably too strict.
Synthesizing the permissions is quite difficult :(
Robert> 3) src/Makefile.am: cf_gen_DEPENDENCIES must be set with `='
Robert> before using `+='
We recently talked about this with Tom, and we agreed that there is no
reason not to do that (but to protect the user from herself, but it's
not our job). So consider this is solved. I don't have time now, but
I'll submit a patch soon.
For the time being, I suspect you should just not use the HEAD Automake.
Re: problem: uninstall-am in makefile with no install targets and non-GNU make.
Thanks Akim, adding that line should fix the make uninstall problem.
However the makefile.in's created by automake are now corrupt:
I get 1001 errors (I CVS updated first).
The errors I get are (single samples of each)
1) AMDEP does not appear in AM_CONDITIONAL
2) snmplib/Makefile.am:14: DEFS multiply defined in condition TRUE
DEFS (User, where = 14) =
{
TRUE => -DSQUID_SNMP=1
}
3) src/Makefile.am: cf_gen_DEPENDENCIES must be set with `=' before
using `+='
The automake was current as of 4-5 days ago, so I assume these result
from your recent patches. Could you make some suggestionsas to what is
wrong?
for 1) I have no idea, no line numer is spat out with the error.
for 2) , there is no line 14, the file is 13 lines long (
==
## Process this file with automake to produce Makefile.in
##
## Makefile for libsnmp.
##
noinst_LIBRARIES = libsnmp.a
libsnmp_a_SOURCES = asn1.c parse.c snmp_vars.c \
coexistance.c snmp_api.c snmp_error.c \
mib.c snmp_api_error.c \
snmp_msg.c \
snmp_pdu.c snmplib_debug.c
INCLUDES= -I$(top_builddir)/include -I$(top_srcdir)/include
VERSION = 3.4
DEFS= -DSQUID_SNMP=1
==
for 3), I used
cf_gen_DEPENDENCIES += cf.data.pre
because I didn't want to override the implicitly generated dependencies.
cf.data.pre is a data file used by cf_gen - it isn't really valid as a
dependency and I will fix this up myself.
However - it seems sensible to me to allow the user to add dependencies
without overriding the autogenerated ones.
Rob
- Original Message -
From: "Akim Demaille" <[EMAIL PROTECTED]>
To: "Robert Collins" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, April 11, 2001 6:04 PM
Subject: Re: problem: uninstall-am in makefile with no install targets
and non-GNU make.
>
> Try to add
>
> 'uninstall-am' => 1,
>
> in the structure below in automake.in. Keep us informed! Thanks!
>
> Akim
>
> # List of targets we must always output.
> # FIXME: Complete, and remove falsely required targets.
> my %required_targets =
> (
>'all' => 1,
>'dvi' => 1,
>'info' => 1,
>'install-info' => 1,
>'install' => 1,
>'install-data' => 1,
>'install-exec' => 1,
>
># FIXME: Not required, temporary hacks.
># Well, actually they are sort of required: the -recursive
># targets will run them anyway...
>'dvi-am' => 1,
>'info-am' => 1,
>'install-data-am' => 1,
>'install-exec-am' => 1,
>'installcheck-am' => 1,
>
>'install-man' => 1,
> );
>
Re: problem: uninstall-am in makefile with no install targets and non-GNU make.
Try to add 'uninstall-am' => 1, in the structure below in automake.in. Keep us informed! Thanks! Akim # List of targets we must always output. # FIXME: Complete, and remove falsely required targets. my %required_targets = ( 'all' => 1, 'dvi' => 1, 'info' => 1, 'install-info' => 1, 'install' => 1, 'install-data' => 1, 'install-exec' => 1, # FIXME: Not required, temporary hacks. # Well, actually they are sort of required: the -recursive # targets will run them anyway... 'dvi-am' => 1, 'info-am' => 1, 'install-data-am' => 1, 'install-exec-am' => 1, 'installcheck-am' => 1, 'install-man' => 1, );
Re: 77-language-class.patch
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: Tom> This is ok. Tom> But before we check it in let's make sure we are very clear on Tom> the licensing issue. In GNU, licensing comes before all. Yep. I can't get any definitive answer. Nothing in the FAQ's I read but the fact that modules should state their license. Good. But what when they don't :( Tom> This might mean that we'll be restricted to whatever Tom> Class::Struct comes with the Perl version we decided on. That Tom> would be unfortunate, but we've lived with implementation Tom> deficiencies in the past (i.e., Perl 4) Bleah! Then I have an idea: let's rewrite Automake in Autoconf :)
Re: 82-lang-finish.patch
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: > "Akim" == akim <[EMAIL PROTECTED]> writes: >>> I have a mild dislike for this. If `finish' were a method then we >>> could simply inherit it. Akim> I do share your dislike for the structure, but please, note that Akim> we are defining methods per _object_. Cleaner would mean one Akim> *class* per language, which seems overkill to me. Tom> Really? Why? To me it seems natural. Yes, you are right. But we still have to face the circular dependency thingy. I don't think Automake is ready for this.
Re: 79-lang-compile.patch
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: Tom> One last thing about separating into modules: we'll probably want Tom> to put the module files into their own directory in the source Tom> and install trees. Let's start a new directory for this sooner Tom> rather than later. I agree! Likewise for *am files. But I'd like to flush my patches first, please. In fact, I'd like to doc/ and man/ and config/ too.
problem: uninstall-am in makefile with no install targets and non-GNU make.
with this makefile.am: === EXTRA_LIBRARIES = libregex.a libdlmalloc.a noinst_LIBRARIES = libmiscutil.a @LIBREGEX@ @LIBDLMALLOC@ libntlmauth.a libmiscutil_a_SOURCES = rfc1123.c rfc1738.c rfc1035.c rfc2617.c util.c \ getfullhostname.c base64.c uudecode.c splay.c safe_inet_addr.c \ iso3307.c snprintf.c md5.c radix.c stub_memaccount.c Array.c \ Stack.c hash.c heap.c html_quote.c # $(top_srcdir)/include/version.h should be a dependency # LIBOBJS was included here: what is it used for ? libregex_a_SOURCES = GNUregex.c libdlmalloc_a_SOURCES = dlmalloc.c libntlmauth_a_SOURCES = ntlmauth.c INCLUDES= -I$(top_builddir)/include -I$(top_srcdir)/include === the resulting makefile is broken with non GNU make. it has uninstall: uninstall-am and in .PHONY: ... uninstall-am ... but on openBSD I get "make: don't know how to make uninstall-am. Stop." with make uninstall. Any pointers?
Re: Default postscript cleans miss *.cps & *.fns.
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> elsif (/^\@(syncode|print)index \w+ (\w*)/) { push
Akim> @clean_suffixes, "$1s";
Tom> Shouldn't that be "$2s" here?
Yes, definitely. Thanks!
Re: Scripts...
> "Alex" == Alex Turner <[EMAIL PROTECTED]> writes: Alex> Cool - actualy I forgot to ask if this is a sane way to do it Alex> for C. I would much prefer it generated a header file with it Alex> in somewhere. Described into the details in CVS Autoconf's documentation.
Re: Patch: make dist in subdirs before handling the current directory
- Original Message - From: "Tom Tromey" <[EMAIL PROTECTED]> To: "Robert Collins" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, April 11, 2001 4:01 PM Subject: Re: Patch: make dist in subdirs before handling the current directory > > "Robert" == Robert Collins <[EMAIL PROTECTED]> writes: > > Robert> * distdir.am: Recurse into subdirs before handling files > Robert> in the current directory. > > Robert> This patch reverses the order of subdir processing with > Robert> current directory files for the make dist target. > > I don't think this is the right thing to do. Reversing the order > solves the problem in one particular case, but it might introduce new > problems we don't know about. That becomes more true if/when we have > the dist target depend on `all'. > > Instead I think the right thing to do is for automake to notice when > it is dealing with a dist-able object in a subdir and then at dist > time make the subdir and fill it with those files. This will let > things work even when the subdir doesn't have a Makefile of its own. > We already have most of the code in place to do this; it shouldn't be > very hard to finish. > > Tom > Excellent. I agree that thats the right way to do it - I simply needed an interim fix so I could actually run make dist :] Rob
