ide a
GCC which only produces 64-bit applications.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
gs2 = $(am__test_logs1:.log=.log)
---
am__test_logs2 = $(am__test_logs1:.exe.log=.log)
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
) sometimes don't work as 64-bit
code.
Compiler defaults are simply a matter of policy which is up to the GCC
maintainers, the individual Linux distribution, or even the person who
installs GCC, to determine.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/
logs2 = $(am__test_logs1:.exe.log=.log)
TEST_LOGS = $(am__test_logs2:.sh.log=.log)
all:
Xecho .$(TESTS).
Xecho .$(am__test_logs1).
Xecho .$(am__test_logs2).
Xecho .$(TEST_LOGS)
END
make
Thanks,
Ralf
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
G
package information are best obtained in a JIT
fashion so that it is always available when needed (and not before)
and there is a minimum of regeneration and building due to an
increment in the version information.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org
be able to use pkglib_LIBRARIES for this purpose.
You may still be able to work around the problem as long as you avoid
using Automake reserved variable names with well defined
functionality.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
of C# is not to have "real .so files".
C# and .net's JIT linkage and compilation seem to go hand in hand. C#
should produce something similar to .net assemblies. These are rather
similar to "real .so files" except that they require a special VM to
load them.
versions). What does './libtool --version' (using the libtool the
package is using) say?
Regardless, this appears to be a libtool problem rather than an
automake problem so it should be discussed on the libtool list.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.t
s depend on the ability of the version control system, and the
package owner's ability to maintain the version control system.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
On Fri, 5 Jun 2009, Peter Johansson wrote:
Bob Friesenhahn wrote:
Doesn't any approach which depends on an automatically generated file
assure that the version control system is one step out of date? Every time
you do a 'commit' the version file is one step newer and therefo
ring a version file (which may be a target of make) works for me.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
ems besides git.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
the wrong library being used. See the
documentation.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
On Tue, 9 Jun 2009, aaragon wrote:
and it doesn't work. However,
LDADD = $(top_srcdir)/yafeq/libyafeq.la
does work. So I hope this is finally the way to do it.
Remove the
$(top_srcdir)/
prefix. It is not needed and will likely cause problems. Let
Automake do its job.
Bob
-
place
top_srcdir with top_builddir.
It is not necessary to specify top_builddir because that is where the
Makefile is written and the directory where the build is performed.
As you say, specifying $(top_srcdir) may cause harm since it is likely
to break VPATH builds.
Bob
--
Bob Friesenhahn
On Tue, 9 Jun 2009, Peter Johansson wrote:
Bob Friesenhahn wrote:
It is not necessary to specify top_builddir because that is where the
Makefile is written and the directory where the build is performed. As you
say, specifying $(top_srcdir) may cause harm since it is likely to break
VPATH
favor of using an expression.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
popular" by any stretch of the
imagination. None of my systems (not even Debian Lenny or FreeBSD 7.2)
offers a program named 'xz' by default.
Lzma is a case of the cart being before the horse. In the case of
gzip and bzip2, these file formats were already quite heavily used
w
me as well so
apparently it is not properly portable. Normally I expect open source
software to build with GCC but such was not the case for me with 'xz'.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick
On Sun, 14 Jun 2009, Antonio Diaz Diaz wrote:
Bob Friesenhahn wrote:
Is lzip expected to be portable? Did you receive the email (and patch)
that I sent to you a day ago regarding a portability issue?
Lzip is supposed to be portable to posix systems with GCC. It is easy to port
lzip to some
g.
gmake[3]: *** [test-suite.log] Error 127
The package uses Automake 1.11 with these Automake options:
AUTOMAKE_OPTIONS = 1.11 subdir-objects parallel-tests color-tests
dist-bzip2 dist-lzma foreign
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
Grap
don't mind explicitly splitting internally if there is
still a way for the user to do the standard 'make check' and 'make
distcheck' (with reliable ultimate failure on test fail) and see a
total report for all of the tests at the end.
Bob
--
Bob Friesenhahn
bfr
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
in the configure script where the
user can't do anything about it (other than using CFLAGS/LDFLAGS).
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
e a requirement to support
the many other version control systems as well.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
at time, many version control systems have come and gone and
gained/lost popularity. Even the Linux kernel has changed source
control systems several times. It seems best to keep autotools
version-control agnostic while enabling application developers and
package maintainers to add en
file outside of the source tree
really works properly.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
hared.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
being installed. A more
This seems like a pretty unreasonable requirement to me. The
install-sh strategy has been working for quite a long time with hardly
any complaint until today.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick
time has come to let folk on the small
proportion of machines without a sufficiently useful install, build it -
exactly as they have to build any other dependency they are lacking.
What other dependency might they be lacking? My own package is quite
large but all of the dependencies are op
ontained, well
supported, and would probably take five or seven years to fully
develop. There have been a number of independent attempts in this
direction but it seems that none has come close to the popularity of
autotools.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://ww
source software seem confusing and inconsistent.
It means automake is pushing around package maintainers to modify their
packages to automake's behavioral changes.
Quite annoying indeed.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsM
h back-pressure from the masses, this
simple boolean can be toggled to the legacy default used since the
dawn of GNU. Open source is for users and the users have a right to
complain to developers and maintainers.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesyste
t related to build options or the system. This is
why I consider silent mode to be "selfish".
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
to take a look at ImageMagick or GraphicsMagick
Automake makefiles to see how it may be done.
See the hunk of junk at
http://cvs.graphicsmagick.org/cgi-bin/cvsweb.cgi/GraphicsMagick/PerlMagick/Makefile.am
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org
ings better.
It seems that a problem is that much of the Makefile.am file is simply
copied to the output Makefile.in and so these parts would need to be
re-written rather than copied. The good news is that perl is good at
re-writing text.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http
rm -f $$list || exit $$?; \
test -n "$(EXEEXT)" || exit 0; \
list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
echo " rm -f" $$list; \
rm -f $$list
Is there a way to make this quite a lot faster?
Thanks,
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
directory is already clean.
Usually I don't care much about 'make clean' times but when I am
chasing down compilation warnings I tend to do a lot of cleans.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Main
ftware are included, or
otherwise formally made available.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
e tar archive will be able to extract
all the files even if the user is unprivileged.
Does anyone have a cite for what version, how old?
(sounds like mid 1980's, actually).
It must not be that old since I have distinct memories of such
problems.
Bob
--
Bob Friesen
permissions limited only by the current umask and OS-specific
rules (as per mkdir(2)). Much of this is based on behavior of the tar
command used for the extraction.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
on't be widespread enough
to constitute a solution anytime soon.
I am not sure what you mean by above. My point is that configure
can't rely on UID 0 or user 'root' to decide if it should behave
differently.
Certain major operating systems have been using 'roles&#
e fully known to one makefile
and makes it possible to avoid using libtool convenience libraries.
Creating libtool convenience libraries for the sole purpose of being
able to refer to the object files in a different directory is
wasteful, even though its a common usage.
Bob
--
B
On Mon, 14 Dec 2009, Martin Kalbfuß wrote:
When I have a look at the config.h I see only empty defines like
#define SKMajor
What's wrong here?
Shell lines prior to AC_INIT are ignored. This is definitely an
annoyance.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us,
e used to find the program's data
files.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
brary that you
are trying to link against. This results in two versions of the same
library being used in the build.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
list.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
ls: Why do passenger trains have windows?
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
information in the installer license text ("Do you accept?")
area.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
lution could allow a module to resolve the symbol in
the static library part introduced by another module. When that
module is later unloaded, then things go "boom" since the code being
used is no longer present. There is also the small matter of wasted
memory if duplicate code is lo
al' library, leaving
some symbols unresolved and without knowing where the symbols will
come from. Systems which come to mind which don't support this are
Microsoft Windows and IBM's AIX.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/
is largely built by Automake:
http://www.graphicsmagick.org/
I don't claim that it is anything exciting.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
a/Xz Utils, and lzip is similar
to gzip and bzip2 in package size and complexity. This seems like
quite an advantage.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
d in your link which uses threads,
but which was built with GCC rather than the Sun compiler. Libtool
stores the -pthread option in the installed .la file. The .la files
are just ASCII text so you can easily inspect their content.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us
correspondence.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
option to be preserved, or dependent programs/libraries might not
work. This is because Solaris provides some stub pthread functions
via weak symbols which do nothing (and return an error code) so that
thread-safe libraries may be used by single-threaded programs.
Bob
--
Bob Friesen
happens to (usually) work does not make it
good.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
log is not really very helpful. What would be much more
helpful is if a full path from root is reported so that I can view
the right file regardless of my current directory.
Thoughts?
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
Grap
ck to a terminal session, it is not
always easy to find the relevant test-suite.log file.
If an absolute path is provided instead, then there is no confusion.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
d need to provide
an absolute path and which don't need to, so that we can fix all
instances and not keep iterating.
That would be a good plan.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
ng of check_PROGRAMS and still use the
generated parallel-tests using TESTS? Thanks.
You are trying to do something which violates the GNU coding
standards since 'check' has a standard definition.
If you use a different target name then there should be no problem:
checkprogs :
able program, you need to take
care that any embedded environment variables don't cause a security
problem.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
lity won't hurt of course.
Are you assuming 'make dist' after 'make' or 'make dist' from scratch?
Other than the time spent compressing data, 'make dist' after 'make'
should be quite fast.
It may be that dimished returns become extrem
same can be said about currently used -9 for lzma, no?
Yes. The argument is that it should be possible to optionally set the
compression level. In most cases, the compression default should be
the tool's compression default.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http
ent, it is easy enough to
add a project-specific 'make release' target which adds the XZ_OPT
option and invokes 'make dist' or 'make distcheck'. Overriding an
already set makefile variable is likely not portable.
Bob
--
Bob Friesenhahn
bfrie...@simple.da
27;m willing to break the GCS rule.
My project uses maintainer-mode and I always check these generated
files into the source code repository. The end user might not be able
to produce a working set of files based on whatever random autotools
they have on their system.
Bob
hat I do find challenging are projects which provide autotools source
files which don't work with current released FSF autotools, use custom
m4 macros which are not included in the source tree, or indicate which
versions might actually work.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.t
On Sat, 19 Jun 2010, Peter Johansson wrote:
Is there a way to tell automake to ignore the INSTALL file, or is there
another way to achieve similar thing.
My best guess is to add 'foreign' to AUTOMAKE_OPTIONS.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simples
. Macros defining
useful values would simply be available in the pre-processor when the
makefile source is expanded. The pre-processor itself can be quite
simplistic.
The value provided by a pre-processor would not be limited to only
nonrecursive makefiles.
Bob
--
Bob Friesenhahn
bfrie
rules.
(If yes, then we could share the rule code text between both.)
Comments?
Thanks,
Ralf
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
On Sun, 1 Aug 2010, Bob Friesenhahn wrote:
am_RECURSIVE_TARGETS
am_RECURSIVE_CLEAN_TARGETS
am_ALL_RECURSIVE_TARGETS
I am not using these in my own makefiles, but perhaps someone else might be.
If there is reason to believe that these variables might currently be used,
then there is
n. The current stunted syntax only exists because it was
easier for a developer back in the early days of Automake development
to require 'make' syntax. Improved substitution syntax is left to the
Automake designer.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.sim
U make.
If depending on GNU make was considered ok, then Automake would have
been developed quite differently than it is. Given current Automake
objectives, it is wise that individual projects also try to avoid GNU
make syntax in Makefile.am.
Bob
--
Bob Friesenhahn
bfrie...@
re/build capability
using only portable aspects of tools and with no special build
software (e.g. m4 macros) already installed on the system.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
FS.
The timings I posted were for local access.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
st suite.
More recently, I have started to install the Fortran components so I
should be able to remove the overrides. Since I try to enforce using a
particular GCC version in config.site, I will probably set this
definition to use gfortran.
Bob
--
Bob Friesenhahn
bfrie...@simple.da
ather than
Linux.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
This means that there should be no performance difference.
Perhaps you have a problem with your system or should be using 'vim'
rather than 'gvim'?
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsM
d before the "normal" prerequisites of 'all' are dealt with.
Yay! This is something which annoyed me with the (supposedly)
non-recursive build. It sure would be nice to get rid of it (if
possible). :-)
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesy
(or some extra substitution script code). It may be that large
performance wins can be obtained via relatively simple changes.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
uite a good job with Automake.
It is wrong to think that lack of popularity means that the software
is not in effective use somewhere or is woefully incompete. Only
analysis or real-world testing can show how effective the package is.
However, it is not Automake.
Bob
--
Bob Friesenhahn
bfrie...
he current binary, and that
dependency information from the build system needs to be cached in
'make' include files.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
the hardware clock. I am not aware of a more effective
method than using ntp.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
On Thu, 13 Jan 2011, Steffen Dettmer wrote:
On Thu, Jan 13, 2011 at 3:39 AM, Bob Friesenhahn
wrote:
While GNU make is a really good 'make' program, I think that 'make' in
general is a flawed concept.
Could you please explain this a bit?
Make depends entirely on
he build inventory can be
updated and nothing needs to be rebuilt. In this case, the timestamp
is simply an optimization.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
On Thu, 13 Jan 2011, Ralf Wildenhues wrote:
* Bob Friesenhahn wrote on Thu, Jan 13, 2011 at 07:50:08PM CET:
Regardless, 'make's use of timestamps based on simple "newer than"
analsys is not very robust in our real world.
That may be true, but this issue is completely o
uld run 'make -d' on their own projects.
Those that feel that all that counts is the time for a from-scratch
build and developer rebuilds are not important might consider that
/bin/sh is a more efficient build tool than 'make' for that particular
case. :-)
Bob
--
Bob
Ralf,
Where do these terms 'alpha' and 'beta' build system originate from?
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
ts do have
incentive to offer working VPATH support because it is so useful, and
because Automake uses it.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
rator might need to bless the posting so that it goes through.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
parallel compilation ?
Maybe you should make pdf.la dependent on ibfitz.la libdraw.la ...?
Do you mean for your build to be non-recursive?
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
benefits of config.h, but in a better form.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
On Tue, 31 Oct 2000, Simon Richter wrote:
> On Mon, 30 Oct 2000, Bob Friesenhahn wrote:
>
> > If we should not be installing config.h files, then it would be
> > beneficial for Automake (or Autoconf) to support an automated way to
> > provide the benefits of config
;t Automake itself intended to be eventually
re-written in guile?
If you don't like the current languages that guile supports, you can
always write a Python implementation that runs under guile (as they
did for Tcl) and implement using Python syntax.
Ducking and running ...
Bob
talled since it has access
to the libMagick.la file, however, it failed to supply the required -L
option to the linker so that the installed library is found.
Bob
======
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
501 - 595 of 595 matches
Mail list logo
