ould be
like putting chrome mag wheels on a Rolls Royce. :-)
Bob
==========
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
or in the
directory where the source files live. An even better solution would
allow the user to specify where intermediate files are placed on a
per-library and per application basis.
Is there a way to convince Automake to behave more usefully?
Bob
======
Bob F
ibtool will have some problems as well.
Bob
==========
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
options augment the value provided via INCLUDES.
Bob
==========
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
ctive name prefixing whereas if 'subdir-objects' is supplied, the
name prefixing is unneeded and undesireable.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
ne for me, with non recursive make for 2 years now.
> Not to say there are not issues to find :}.
Right. I have not noticed a libtool problem when using the recursive
make. I am not using SUBDIRS so the only issue I have noticed thus
far is odd-naming of intermediate objects.
On Tue, 25 Nov 2003, Alexandre Duret-Lutz wrote:
> >>> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes:
>
> Bob> The Automake documentation claims that 'INCLUDES' is the
> Bob> equivalent of 'AM_CPPFLAGS'. However, I find th
d-postgres_SOURCES ?
Bob
==========
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
automatically supply the
correct --tag option at the correct points.
Bob
==========
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
pattern rules use LTCOMPILE and
friends.
The libtool --tag option must appear before $(CC).
I do not see a trivial way to add the --tag option to Makefile.in.
Bob
On Tue, 25 Nov 2003, Bob Friesenhahn wrote:
> In a build environment I am creating using Automake 1.7.9 & CVS
> libtool, GC
ies
> the compiler (his internal var is base_compile) as 'ccache', and fails.
>
> Since Libtool is not 'wrong' and I don't see good ways to change its
> command line parsing without breaking it, I chose to quote the compiler
> name in automake invocations o
. Sometimes configuring using
the alternate compiler driver is not desireable since it may be doing
exotic things like memory or CPU profiling during the configure run.
Bob
==========
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
RCES
This would be extremely useful since it would allow a package's
directory organization to be re-arranged without excruciating pain.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
-tag=TAG`"
This doesn't seem like good advice given that due to recent libtool
changes, both Automake's Makefiles and libtool itself will be
generated at the same time (at the end of the configure run). :-)
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
On Sun, 30 Nov 2003, Alexandre Duret-Lutz wrote:
> >>> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes:
>
> [...]
>
> Bob> In other words, dealing with junk like
>
> Bob> apps_build_postgres_src_build_postgres_SOURCES
>
> Bob>
On Tue, 2 Dec 2003, Robert Collins wrote:
> On Tue, 2003-12-02 at 02:10, Bob Friesenhahn wrote:
> > > Hmm, I'd prefer to do it via the include mechanism - see my crude, but
> > > effective updated proof of concept - posted here a minute ago.
> >
> > I like yo
t;read only", or personal preference) that both mechanisms
should be supported.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
manually smashed to '_'.
This is very tedious and error prone, and is something that Automake
should fix.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
ons.
Certainly this can be accomplished by overriding Automake's standard
LINK and COMPILE definitions, but overriding standard definitions is
risky.
Bob
==========
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
On Thu, 4 Dec 2003, John Darrington wrote:
> On Wed, Dec 03, 2003 at 02:38:52PM -0600, Bob Friesenhahn wrote:
> Does src1/foo.c exist?
>
> Yes.
>
> Are you using Automake 1.7.9?
>
> No. I was using 1.7.6 and it seemed that atl_SOURCES=src1/foo.c
> works
way to override common flags at any level.
Bob
==========
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
ion with Autoconf, Automake already provides the ability to
build from outside of the source tree. What purpose do you need to
use VPATH for?
Bob
==========
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
On 9 Dec 2003, Tom Tromey wrote:
> >>>>> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes:
>
> Bob> In other words, dealing with junk like
> Bob> apps_build_postgres_src_build_postgres_SOURCES
> Bob> is very tiring and failure prone. Is t
f you are exceedingly lazy, you might want to look for a new line of
work. :-)
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
mbedding libtool in
your package, then you should definitely include AC_PROG_LIBTOOL in
configure.ac.
> Thanks for your help,
> -Billy
>
> [1] http://mail.gnu.org/archive/html/automake/2002-11/msg00046.html
>
>
>
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
s like the result of an Automake bug. Is it possible that
Automake 1.7.9 does not remove its distribution file via the
'distclean' target?
Bob
==========
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
filing.
>
> Is there a (better) way to do that using GNU Automake? I'be been
> browsing the archives for a while but couldn't find anything.
>
> cheers,
> dalibor topic
>
>
>
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
On Wed, 10 Dec 2003, Dalibor Topic wrote:
>
> Bob Friesenhahn wrote:
> > You can use Automake conditionals. These are configure-time
> > conditionals rather than make-time conditionals.
> >
> > You could add --with-check and --with-prof options to your configure
On Wed, 10 Dec 2003, Alexandre Duret-Lutz wrote:
> >>> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes:
>
> Bob> I am working to get the package I support to support the 'distcheck'
> Bob> target. The distcheck target fails with:
common into a temporary
> directory and then build libtarget.a.
>
> marty [EMAIL PROTECTED]
> Don't confuse education with schooling.
> Milton Friedman to Yogi Berra
>
>
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
n GNU make. Then we
> could replace all those rules with a single "%.o: %.java".
This doesn't seem to be necessary.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
On 16 Dec 2003, Paul D. Smith wrote:
> %% Bob Friesenhahn <[EMAIL PROTECTED]> writes:
>
> bf> Per-subdirectory rules and definitions can be added in order to
> bf> significantly reduce the amount of redundant code, and to
> bf> re-enable the capability to
name so it is still comprehensible.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
help eliminate the size increase caused by the
directory path itself. For typical subdirectory path lengths, this
could result in a 40% Makefile size reduction.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
On Tue, 16 Dec 2003, Alexandre Duret-Lutz wrote:
> >>> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes:
>
> Bob> Another thing that would help reduce Makefile size is to
> Bob> introduce synonyms for subdirectory paths.
>
> Better: LZW compre
file.am files
directly ...
Bob
==========
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
On Thu, 18 Dec 2003, Ralf Corsepius wrote:
> On Wed, 2003-12-17 at 16:01, Bob Friesenhahn wrote:
> > On Wed, 17 Dec 2003, Lars Hecking wrote:
> > >
> > > What about an automake option then to generate Makefiles for GNU make?
> >
> > How about a new binary
r)/project2/sublevel/inc
Note that abs_top_srcdir calculation was broken in Autoconf 2.58. It
is fixed in 2.59.
Rather than using INCLUDE you should use AM_CPPFLAGS. For example
AM_CPPFLAGS = -I$(top_srcdir)/project2/sublevel/inc
Bob
==
Bob Friesenhahn
[E
ranslate paths for "native" Windows binaries, or where
the automatic path translation fails.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
could be written which observe what works and what doesn't.
Maybe in an hour or so, a feature-based libtool would come up with the
right answers. Most people don't have that long to wait.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
quot;;). At that
time feature-based testing was relatively new and was being
incorporated in open source packages. Based on the ease of installing
most open source packages that provide a "configure" script, it seems
that feature-based testing has proven to be a resounding success.
Bob
ee since they have intentionally avoided discriminating
between Linux distributions. Even Linux 'uname -a' is useless to
determine the Linux distribution name.
It is way to late to even think about changing things now.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
ue to some hap-hazard lib_LTLIBRARIES list order (e.g. they
could be in alphabetical order).
Bob
======
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
t; somewhere. I wanted to do something like:
>
> ifeq ($(OSTYPE),solaris)
> export SOCKET = -lsocket
> endif
>
> Do I do this in configure.in somehow or in Makefile.am? Is there a
> better way anyone can suggest. I would think something like this is a
> common problem
of tools used in the subdirectory key
off this older host tripplet. They would misbehave if they were
directed to use the newer config.guess.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
s. Usually when used in conjunction
with libtool. :-)
On the flipside, the config.guess output which is in flux is usually
related to new versions of systems that few people have even heard
about.
Bob
==========
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
t recall Automake misbehaving at run-time due to an
incompatibility, but it is possible that it may have happened before
and I just don't remember.
Upgrading Autoconf is much more of a concern than upgrading Automake.
Unfortunately, newer Automake's require newer Autoconfs.
Bob
to ensure that
dependent software does not break. Perl 5.6.1 comes standard with many
existing systems.
Perl has worked fine since the beginning so I suggest that the minimum
version be the minimum version that can be reasonably tested due to
availability.
Bob
====
not Automake. Provide a ".in" version of
your script, and then list the desired output file in configure.ac's
AC_OUTPUT() statement.
Then earlier in configure.ac:
FOO=/bar
AC_SUBST(FOO)
an in the .in file
@FOO@
will be substituted with the value of FOO.
Bob
=====
something like
> "/usr/share" in my script.
Do something like
eval "eval DATA_DIR=$datadir"
AC_SUBST(DATA_DIR)
and then use
@DATA_DIR@
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
I am against having separate install targets because GNU makefiles
normally install everything by default and that is what users should
expect. Installing everything is not a problem for distribution
maintainers since they decide which files to package using their
distribution tools.
Bob
nfo-based processing/targets are skipped.
Keep in mind that texinfo is just one method among many (in addition
to 'vi') for generating HTML documentation. Presuming that the GNU
standards are extended to include HTML, if the user does 'make
install' and the package provi
On Tue, 17 Feb 2004, Bruce Korb wrote:
> Bob Friesenhahn wrote:
>
> > I am against having separate install targets because GNU makefiles
> > normally install everything by default and that is what users should
> > expect. Installing everything is not a problem for dist
ions. If not, then it is broken.
This could be handled similar to the way Automake tests for a recent
enough Python (i.e. via an Autoconf macro).
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
ove command before installing it
>
> Any ideas? I suppose I could make a convenience library that they both
> depend on, is this the only way?
>
> Thanks,
> Dale
> --
> Dale E. Martin, Clifton Labs, Inc.
> Senior Computer Engineer
> [EMAIL PROTECTED]
> htt
On Fri, 20 Feb 2004, Alexandre Duret-Lutz wrote:
>
> Thomas> Are there known issues with cygwin, and automake-1.8.2?
>
> No reports yet. Does the test suite pass?
GraphicsMagick builds fine under Cygwin. It uses Automake 1.8.2 with
AM_CPPFLAGS.
Bob
===
C++ compiler, right?
This distinction is not entirely correct since CPPFLAGS is normally
supplied to the C++ compiler as well. CFLAGS is for the C compiler
and CXXFLAGS is for the C++ compiler.
Bob
==========
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
On Tue, 24 Feb 2004, Ben Pfaff wrote:
> Bob Friesenhahn <[EMAIL PROTECTED]> writes:
>
> > On Tue, 24 Feb 2004, Ben Pfaff wrote:
> >> >
> >> > Of course, when my source files are C++ files the _CFLAGS extension does
> >> > nothing. Changing th
This way the normal Automake install target is used and you
don't need to worry about anything but 'install' in your Makefile.am
files.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
kage supports creating the directory /usr/local (as Automake
does by default) should this directory be recursively removed if a
package is uninstalled?
Bob
==========
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
On Tue, 2 Mar 2004, Daniel Reed wrote:
> On 2004-03-02T08:34-0600, Bob Friesenhahn wrote:
> ) On Mon, 1 Mar 2004, Hans Deragon wrote:
> ) >When performing a "make uninstall", I notice that it only deletes the files,
> ) > not the empty directories. It would be nic
le on non-Unix
operating systems. Automake doesn't just run under Unix.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
On Fri, 5 Mar 2004, Frederik Fouvry wrote:
>
> ,-- On Wed, 3 Mar, Bob Friesenhahn wrote:
>
> [...]
>
> | It is not always easy to see if a directory is empty. For example,
> | when NFS is being used, sometimes .nfs files are created in the
> | directories, so the direc
.
Using run-time Makefile includes is not portable.
Bob
==========
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
tanding of library dependencies (which are
already specified piecemeal in individual Makefile.am files). One way
to accomplish this may be to maintain a top-level file which records
the order that libraries were linked during the build.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
On Mon, 15 Mar 2004, Fredrick Meunier wrote:
>
> Bob Friesenhahn wrote:
> > The fundamental problem is that Automake does not have an overall
> > coherent understanding of the library dependencies when libraries are
> > built using a recursive build. Without u
in an associated .la file.
Bob
==========
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
On Mon, 12 Apr 2004, Alien9 wrote:
> so how can i get it out of that .la file?
If you can locate the .la file then it should be as simple as
eval `grep 'dlname=' $file`
Since the line looks like
dlname='libpstoedit.so.0'
Bob
=======
e a maximum
file name length of 99 characters in Automake? One way to enforce
this is to use sed to truncate file names longer than 99 characters
before passing them to tar so that tar complains/fails during 'make
dist'.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
Apparently the key to building Automake 1.8.3 under FreeBSD is to use
BSD make rather than GNU make.
However, Automake 1.8.2 configures and builds just fine using GNU
make.
Bob
On Sat, 17 Apr 2004, Bob Friesenhahn wrote:
> Failure to configure and build Automake is a first for me. This
c/gnu/automake-1.8.3% make
Making all in . doc m4 lib tests
cd: no such file or directory: . doc m4 lib tests
*** Error code 1
make: Fatal error: Command failed for target `all-recursive'
Bob
======
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems
1.8.3.
I suspect that there is something wrong with the Automake 1.8.3
tarball. Maybe there is a directory timestamp problem?
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
ib tests
cd: no such file or directory: . doc m4 lib tests
gmake: *** [all-recursive] Error 1
% grep 'SHELL =' Makefile
SHELL = /bin/zsh
Bob
==========
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
broken. It is incorrect to assume that the user's
login shell is the shell that should be used.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
s the problem, I will submit an appropriate patch for Autoconf.
This change resolves the problem.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
esent in Autoconf), so one might expect
> Automake to also consider zsh a usable shell (by employing the same zsh goop,
> for instance).
I agree with your conclusions. Automake Makefiles should be more
robust.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
> [EMAIL PROTECTED]
>
>
>
>
> __
> Do you Yahoo!?
> Yahoo! Photos: High-quality 4x6 digital prints for 25ยข
> http://photos.yahoo.com/ph/print_splash
>
>
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
Bourne shell in this respect.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
s problem?
Bob
======
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
he problem three times already while using Automake
1.8.3. I did not see it with 1.8.2 (which was used for quite a
while), but I did see it several minor releases back (don't remember
which).
Bob
On Tue, 20 Apr 2004, Bob Friesenhahn wrote:
> I am once again experiencing problems with Autom
On Wed, 21 Apr 2004, Ralf Corsepius wrote:
> On Wed, 2004-04-21 at 04:35, Bob Friesenhahn wrote:
> > I am once again experiencing problems with Automake leaving behind the
> > distribution files it built so 'make distcheck' fails:
> >
> > ERROR: files le
f maintainers have decided
> to avoid that list.
Autoconf 1.12 is an anchient legacy version dating from eight years
ago. The current Autoconf is 2.59. If no one responded, it was
probably because your request was similar to proposing a design change
to the Model T Ford.
Bob
=====
MAKEFLAGS))),--silent)
This looks like GNU make syntax to me. Automake does not (and should
not) depend on GNU make.
Bob
==========
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
ted in silent mode by default
since it is assumed that maintainers/porters are the only ones who
really need the extra information.
Bob
======
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
On Thu, 20 May 2004, Albert Chin wrote:
> On Mon, May 17, 2004 at 11:24:49AM -0500, Bob Friesenhahn wrote:
> > On Mon, 17 May 2004, Jan Beulich wrote:
> >
> > > I was expecting this sort of answer, but was hoping that then I would
> > > also get a pointer to how
text.
Bob
======
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
capability was removed.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
On Tue, 25 May 2004, Albert Chin wrote:
On Sun, May 23, 2004 at 03:20:35PM -0500, Bob Friesenhahn wrote:
Currently Automake Makefiles include text like:
LTCXXCOMPILE = $(LIBTOOL) --mode=compile $(CXX) $(DEFS) \
$(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS
sbl-xbl.spamhaus.org alone would probably work wonders.
Usually this is good, but lately I have been noticing that substantial
email is arbitrarily rejected due temporary local DNS issues or bugs.
It is not pleasant to be on the wrong end of this.
Bob
==========
Bo
On Sat, 29 May 2004, Alexandre Oliva wrote:
On May 26, 2004, Albert Chin <[EMAIL PROTECTED]> wrote:
On Sun, May 23, 2004 at 03:20:35PM -0500, Bob Friesenhahn wrote:
Notice that there is no means provided to add libtool specific
options.
Why not:
AM_CXXFLAGS += [your additions]
Because
ake manual. This should be a requirement for
any GPLed or LGPLed package since failure to support this flexibilty
is a failure to support the spirit of GPL and open source in general.
Any recipient of the package should have the ability to become a
package "maintainer" without removing
and making use of
it if it is available (and works)?
Bob
==========
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
On Wed, 23 Jun 2004, Warren Young wrote:
Bob Friesenhahn wrote:
I have learned that using 'rsync' to copy files improves the install time
quite dramatically for repeat installs.
This should only be true when the transfer channel is much slower than the
disks on which the files
elieve that rsync looks at the absolute time stamp (with optional
fuzz factor) while it seems that GNU 'cp -c' only checks the source
file's date to see if it is newer and does not check file size.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
U mailing lists. This policy is one reason why there is so
much SPAM on the lists. The alternative is that many useful postings
would not be posted to the lists.
Bob
======
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
s that what you
intended?
Bob
======
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
the source tree doesn't make sense since the
software may not be related, or there may replicated source files.
Bob
==========
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
On Wed, 14 Jul 2004, Jesse Barnes wrote:
On Wednesday, July 14, 2004 3:59 pm, Bob Friesenhahn wrote:
Probably gtags is not implemented very well.
Sounds like it.
It seems like there should be a rule to collect the source file list
from all Makefiles (including subordinate Makefiles) followed-up by
e subordinate builds end up using a
32-bit compiler along with options which only work for the 64-bit
compiler so 'make distcheck' fails.
Is use of any old compiler accidental or intentional?
Bob
==========
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
1 - 100 of 595 matches
Mail list logo
