Re: More fun with BUILT_SOURCES

2000-11-14 Thread Braden McDaniel

On 14 Nov 2000, Alexandre Oliva wrote:

 On Nov 14, 2000, Braden McDaniel [EMAIL PROTECTED] wrote:
 
  I realize that BUILT_SOURCES is known to be problematic, but I haven't
  found any other solution. Any suggestions?
 
 Add explicit dependencies on it.  There's no other way to ensure it's
 generated.  BUILT_SOURCES used to work only with GNU make.

Each source file for my library depends on the generated header, directly
or indirectly. Is it possible for me to add explicit dependencies *and*
keep the libfoo_la_SOURCES variable? I'm trying to hang on to all of
automake's benefits that I possibly can.

-- 
Braden N. McDaniel  e-mail: [EMAIL PROTECTED]
http://www.endoframe.com  Jabber: [EMAIL PROTECTED]





[Fwd: --add-missing]

2000-11-14 Thread Derek R. Price

Yep.  Looks like that could be used by configure to set, say,
TEX_TEXINPUTS  PDFTEX_TEXINPUTS and prepend include dirs differently
for different targets, but I suspect that if your TeX distribution
includes kpsewhich then your TeX applications can already find the
appropriate texinfo.tex.

Of course, I suppose this could still be used to find a more recent
texinfo.tex than was included with your automake distribution, which
would work slightly better than including an out-of-date texinfo.tex,
but the included texinfo.tex will still render PDF targets unbuildable
since texi2dvi will, by default, prefer a texinfo.tex in '.' over one
elsewhere.

In other words, a complete solution is probably some combination of
these two, so that TEX_TEXINPUTS or PDFTEX_TEXINPUTS is used when
available and the included texinfo.tex is used when the appropriate
texinfo.tex can't be found.

This is a little more work, but it seems much less baroque than mv'ing
texinfo.tex out of the way when a better one is found.  Then again,
maybe you can find a way to make that work.

Derek

--
Derek Price  CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
... one of the main causes of the fall of the Roman Empire was that,
lacking zero, they had no way to indicate successful termination of their C
programs.

- Robert Firth





Hi,

"Derek R. Price" [EMAIL PROTECTED] writes:
 Alexandre Oliva wrote:
  On Nov 13, 2000, "Derek R. Price" [EMAIL PROTECTED] wrote:
   Okay, is there some way short of symlinking the
   /usr/share/automake/texinfo.tex file by hand to make sure that automake
   --add-missing uses the "proper" texinfo.tex file (i.e. the one installed
   with the texinfo package and assumedly the most recent one)?
 
  I'm afraid not.  Any suggestions about how automake could find out
  where texinfo.tex from the texinfo package is installed, assuming it
  is?
 
 Well, after sifting the documentation for my distribution for several hours,
 I have discovered the "texmf.cnf" file.  It appears to define all sorts of
 possible search paths dependant on the format of your input and output files.

Assuming you're using teTeX (likely for most recent UNIX TeX
installations), you look for things using the 'kpsewhich' program,
like in

  kpsewhich texinfo.tex

The texmf.cnf file should be treated as an internal detail.

- Hari
-- 
Raja R Harinath -- [EMAIL PROTECTED]
"When all else fails, read the instructions."  -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing."   -- Roy L Ash




HP 11.0 acc 3.25 help with purify

2000-11-14 Thread Tim Heath

I have modified the make file generated by automake because aCC does
not support the same dependency generation that CC does.  What I don't
understand is how to add another make target so that I can compile for
usage with purify.  I also do not know how I can fix my automake
generated Makefiles to generate dependency information correctly with
aCC.  I would appreciate any suggestions.

Thanks,

Tim Heath




automake make check error (and more, really)

2000-11-14 Thread Brown, Melissa

Solaris-sparc, 2.6, trying to install mysql (done) and php4 my automake
make check is failing and I think it's the reason reason my other make is
failing.. long story. but if you help me with getting my
automake fixed -- it'll probably/hopefully/maybe fix the other one!  :-)
 
If you know what recursive means... you can probably skip all the background
info I gave you and go down to where the -- is for the real
question.
 
I installed the flex-2_5_4a, bison-1_25, make-3_76 and m4-1_4.  I already
had perl-5_005)3 and gzip-1.2.4 installed.
Then I installed autoconf-2.13 and automake-1.4 and mysql-3.23.24-beta
No problems!
 
I wasn't going to install gcc-2.95-2-sol26-sparc-local because I needed
space, but I had to in order to install php-4.0.1
 
So, I did the gcc-2.95-2 install last night.  When I needed more space, I
removed the old gcc 2.8.1 and libstdc++ (the package that used /opt/GCC281)
I also removed an old wu-ftpd260 and some xwindows files that I'm sure I
didn't need.
 
This morning, I did a configure, make, and make install without any
problems.  It didn't work when I tried to bring up the netscape server with
it, so I was going to reconfigure with new options.
 
Now it fails.
I did a reboot between the configure/make this morning and then.  And, I
took a /opt/GCC281/bin out of my path.
 
I think when I did the configure/make this morning, I was using something in
memory.
 
Okay, background in place, here's my question:

I've reinstalled the other packages, just to make sure they were okay.  I
got an error during the make check on automake-1.4, which leads me to
believe it has something to do with the libraries don't ask me why I
think that!!  Here's the error I get when doing the make check on
automake-1.4:
.
.
.
PASS: yaccpp.test
=
2 of 194 tests failed
=
*** Error code 1
make: Fatal error: Command failed for target `check-TESTS'
Current working directory /opt/automake-1.4/tests
*** Error code 1
make: Fatal error: Command failed for target `check-am'
Current working directory /opt/automake-1.4/tests
*** Error code 1
make: Fatal error: Command failed for target `check-recursive'
#

--
Here's the error I get when doing the make on php4.  (the path is to the new
gnu make)
# /usr/local/bin/make
Making all in Zend
make[1]: Entering directory `/opt/php-4.0.3pl1/Zend'
/bin/sh ../libtool --silent --mode=compile c++ -DHAVE_CONFIG_H -I. -I. -I..
-D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEM
ANTICS -D_REENTRANT -DXML_BYTE_ORDER=21 -I../TSRM  -g -O2 -pthreads -c
zend-scanner-cc.cc
In file included from zend-scanner-cc.cc:2570:
zend_operators.h: In function `int is_numeric_string(char *, int, long int
*, double *)':
zend_operators.h:83: implicit declaration of function `int finite(...)'
make[1]: *** [zend-scanner-cc.lo] Error 1
make[1]: Leaving directory `/opt/php-4.0.3pl1/Zend'
make: *** [all-recursive] Error 1

-
It's the same kind of error!!  Recursive??
 
Does anyone know what I'm missing here -- do you think I need to reinstall
the gcc 2.8.1 and the libstdc++ and then reinstall the gcc 2.95-2??
 
Melissa
 
 




Re: HP 11.0 acc 3.25 help with purify

2000-11-14 Thread Paul F. Kunz

 On Tue, 14 Nov 2000 14:39:07 -0700, Tim Heath [EMAIL PROTECTED] said:

   I have modified the make file generated by automake because
 aCC does not support the same dependency generation that CC does.
 What I don't understand is how to add another make target so that I
 can compile for usage with purify.  I also do not know how I can fix
 my automake generated Makefiles to generate dependency information
 correctly with aCC.  I would appreciate any suggestions.

   What I did with the same sort of problem with Sun's CC was kind of
a quick punt. I added to my Makefile.am a good old fashion `depend' target...

---
# For platforms where automake dependency generation doesn't work
depend: $(libhippoplot_la_SOURCES)
$(top_srcdir)/config/makedepend $(DEFS) $(INCLUDES) $(CPPFLAGS) $?

--
where the `makedepend' script drives gcc to create the dependencies
and modify the automake/autoconf generated Makefiles.  Thus I could
use Sun's CC as far as automake was concerned, but manually generate
dependencies by typing ``make depend''.

   The `makedepend' script I copied from some Open Source project some
ten years ago, and it got it from BSD development in the late 80's.
Perhaps there is a better way, but this quick hack worked for me.

P.S.

   Interesting that gcc folk figured out that having the compiler help
you generate dependencies was a useful feature over 10 years ago,
while the expensive compilers you buy from vendors haven't yet.