GraphicsMagick uses a custom TAP-test script (patterned on the example
one from Automake) where there is support for deciding if the test is
expected to fail based on a list of features. For example, the support
for a file format may depend on an optional library and that library is
a "feature
6:48:38PM -0500, Bob Friesenhahn wrote:
> > > It seems a shame that a distribution tarball will lack a source file
> > > due to makefile build rules. Build rules are a simple technical issue,
> > > which have been solved before, and are even already supported by
> >
It seems a shame that a distribution tarball will lack a source file due to
makefile build rules. Build rules are a simple technical issue, which have
been solved before, and are even already supported by Automake.
A project which requires being tethered to a particular computer server,
which spea
it.
Unlike something like CMake, Automake just keeps on working using well
established patterns.
It is possible that something might stop working on a 30 year old
system, but this would not be noticed unless there is a bug report.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http
Automake, I feel that there is too much
effort, and future risk.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
tag
is presumably overridden by CXX.
The end result fails.
Is there a way to solve this problem beyond replicating many modified
Makefile.in hunks into Makefile.am?
I am faced with backing out my attempt for yet another time. :-(
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http
(or able) to solve issues via
extensive processes. They expect that 'make distcheck' will prepare a
clean distribution tarball.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
ich has the benefit of a very
small implementation and more compact coding than xz uses.
I stopped distributing anything but xz format since that is what almost
everyone was choosing to download.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen
s, scripts, libtool, etc.)
for all of the packages it distributes? Besides verifying the original
files which are re-distributed, it might be necessary to verify that
generated files are correct, and are in fact based on the files which
are re-distributed.
Bob
--
Bob Friesenhahn
via
a compromise of his computer.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
bug open already in libtool for the issue with dropping -lm
when mixing C and C++. It is not clear that the C++ linker provides -lm
by default since it seemed to be pulled in by implicit dependencies as
part of the libraries implementation.
Bob
--
Bob Friesenhahn
bfrie...@simpl
GraphicsMagick (which is primarily C code) supports optional linkage
with some C++ libraries. It is my opinion that if a library or program
is linked with C++ libraries (and especially if it is a static build!)
that it should be linked using the C++ linker. Likewise, if a library
or program d
GraphicsMagick (which is primarily C code) supports optional linkage
with some C++ libraries. It is my opinion that if a library or program
is linked with C++ libraries (and especially if it is a static build!)
that it should be linked using the C++ linker. Likewise, if a library
or program d
feature. Automake-generated Makefiles do
not rely on GNU make.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
-time build
so what tangible benefits does --disable-dependency-tracking actually
provide?
If empty files are ok (assuming they are needed at all), can they be
produced with a minimum number of executions of a 'touch' command?
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http
Make fragments.
Lastly, sometimes the files from one VCS are stored within another
(e.g. git in Mercurial) and the tool would need to know the file and
the desired syntax (e.g. glob vs regex).
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsM
this is very obscure and it defeats the purpose, which should be
to encourage verification.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.
On Fri, 8 Apr 2022, Jim Meyering wrote:
On Fri, Apr 8, 2022 at 6:30 AM Bob Friesenhahn
wrote:
Today I saw an announcement for a new version of gzip. It provided
lots of data for how to verify the downloaded tarballs. I recently
saw a very similar announcement for a new version of libtool. I
de on popular systems such as GNU/Linux, then
there is a problem.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
ample descriptions where CPPFLAGS comes after CFLAGS/FFLAGS/etc.,
and sometimes reversed.
I think that this is because it was always assumed that the order does
not matter.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,
On Tue, 15 Feb 2022, Paul Smith wrote:
On Tue, 2022-02-15 at 15:37 -0600, Bob Friesenhahn wrote:
I have been told by several people (who have much more self-esteem
than me) that a build tool called 'cmake' is far more portable than
Autotools so maybe we should make support for 3
citors, or fans, can install
older GNU software first in order to bootstrap sufficiently to a
sufficient level of POSIX compliance.
The well-built systems I bought prior to 2007 are already dead or
difficult to repair.
I do not see any reason to spend any time at all supporting an OS
older tha
e users typically are provided with directory paths which
contain a space and they need to take additional administrative
measures in order to provide directory paths which work with
Autotools.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfrie
ecution time due to the fork/exec
than annoying noise.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
.
However, testing in an empty directory on a system without the
upated ksh93 this looks ok to me:
$ rm -f ; echo $?
0
$ rm -f * ; echo $?
0
so the issue that Automake encountered before must not be exactly
that.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http
a Surendra wrote:
Then how-to install automake in target image.
Download the tarball from https://ftp.gnu.org/gnu/automake/
unpack and follow the instructions in INSTALL; typically somethings like
./configure
make
sudo make install
Peter
--
Bob Friesenhahn
bfrie...@simple.dallas.t
trying to cross
compile a script-based build tool.
If you had a working cross-compiler for RISC-V then you could compile
the software for the target (e.g. using Automake) without needing to
add build tools to it.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesy
d prior to a commit. Then
this issue would not have happened.
Of course make distcheck' takes a long time, and it is possible that
for Automake results depend partially on what has already been
committed and not just what is in the current source tree.
Bob
--
Bob Fr
Unix-type systems put 'lib' in front of the name (e.g.
libcalf.so) and that is what is expected for what compilers/linkers
link against.
There may be more issues than this.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick
with GCC then libtool is not needed.
GCC itself knows how to create shared libraries on popular targets.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simp
desired order, but this approach might
only work if you always build using the top level Makefile.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http
-time basis.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
oftware projects which are mature and heavily used.
Projects operated by billion dollar companies with teams of developers
paid to sit in a cubicles and write free sofware seem to be doing
fine.
Unfortunately, this is not the model for most GNU projects.
Bob
--
Bob Friesenhahn
bfrie...@simpl
your satisfaction.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
components are installed into the software
which uses them. This assures consistent versions. If the libtool
components were not installed and distributed with the package, then
there could be problems as you describe.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesy
It is sometimes said that 'autoreconf --force' will solve all
problems, but in my experience this is not always true.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.
ftware/automake/manual/).
It is definitely worth reading some of the documentation. I see that
section 2 of the Autoconf documentation specifically answers your
question.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,
common approach using Autoconf is to test various
known permutations (starting with nothing, and then adding crypt)
until linking succeeds.
I expect that there is already a macro from the Autoconf macro archive
which handles this case.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http
uding each dependent
application's own configure.ac script) might as well be updated to use
the less-portable yet more convenient modern syntax and this implies
the ability to safely use other modern syntax as well.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesy
assumed that the scripts will remain portable to almost any
system.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public
e
targets) is not safe for parallel use. This is done via a
'.NOTPARALLEL: target' type declaration.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
graphics/GM/aclocal.m4]
Error 1
In my case there is only one active developer so there would not be
actual corruption.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key,
s that it *does* have something to do. It might be
Perhaps this experience is a side effect of my recent experience
(regarding AC_INIT and versioning) and not the normal case.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Main
some other purpose.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
considered a usable system for most purposes. If a project does not
provide a 'maintainer mode' to stop maintainer rules from firing, then
this could impact archaic targets from the early '90s.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/b
rounding shell script might need to be changed if the
underlying implementation changes.
The support for 'distcheck' is excellent.
Regardless, thanks for your ideas and the red alert.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
Graphi
to use the recommended AC_INT strategy
is not without some danger since it is more rigid than the previous
shell-variable based approach. This is particularly the case for the
project version and how the project version is applied when creating
the tarball.
Bob
--
Bob Friesenhahn
bfrie...@simple.da
required.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
CFLAGS and CPPFLAGS
for objects built for those libraries (e.g for different CPU targets),
even if they start from the same source files.
Give it a try and find out!
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer
prefix)/avr/lib/foo
avrbardir = $(prefix)/avr/lib/bar
and then possibly this might work:
avrfoo_LIBRARIES = libfoo.a
avrbar_LIBRARIES = libbar.a
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMag
$(srcdir) && \
( \
for dir in $(DISTDIRS) ; do \
find $$dir -depth -print | egrep -v
'(~$$)|(/\.hg)|(/\.#)|(/\.deps)|(\.pyc)' \
| cpio -pdum $$builddir/$(distdir) 2> /dev/null ; \
done \
) \
)
--
d still a bit recursive.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
On Sat, 24 Aug 2019, Assaf Gordon wrote:
Hello Bob,
On 2019-08-24 5:26 p.m., Bob Friesenhahn wrote:
On Sat, 24 Aug 2019, Assaf Gordon wrote:
hello_LDADD = $(top_builddir)/lib/lib$(PACKAGE).a
datamash_LDADD = $(top_builddir)/lib/lib$(PACKAGE).a
This seems like a bug in those two packages
'hello' program is supposed to be a reference
example of the right things to do.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
/usr/bin/make'
under OmniOSce and under Ubuntu 18.04 LTS using 'bmake'. The test
builds succeeded (even parallel builds), including the test suite.
GraphicsMagick uses a non-recursive build, but does not depend on
gnulib or 'po' files.
Bob
--
Bob Friesenhahn
bfrie...
of operating systems and
compilers and they have little exposure to somewhat older operating
systems and compilers where a warning might appear.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http
your server at the beginning of the test
script and then execute 500 tests on it via the same script, while
terminating the server at the end of the script.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http
are not enough independent TAP tests to keep the
system busy. TAP tests do need to produce the expected number of test
report messages, even if a prerequisite has failed.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer
clude
the case where a project is created which builds several other
projects.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfrie
to be compiled if ya need the
software to compile itself?why?
Perhaps you failed to follow the provided instructions or you are the
first person in the entire world who has encountered this problem.
How did you acquire Automake 1.16? Was it from a release tarball or
from a git clone.
Bob
-
s other than via
parsing pkg-config output and trying to make the best of it.
The GNU standard is that the user (the person controlling the build)
should have control over the configuration.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
On Sat, 29 Sep 2018, Karl Berry wrote:
I might be missing something, but I get that behavior in my automatic
builds by calling 'make check VERBOSE=1'.
Yes! Thank you!!
This does not appear to have any effect when using the TAP framework.
Bob
--
Bob Friesen
lected in order to support pthreads.
Bob
krzysiek
-----Original Message-
From: Bob Friesenhahn [mailto:bfrie...@simple.dallas.tx.us]
Sent: Thursday, 12. July 2018 20:28
To: Dudziak Krzysztof
Cc: automake@gnu.org
Subject: Re: PTHREAD_CFLAGS provided by AX_PTHREAD where best to be atta
an be
annoying just to navigate to the correct test-suite.log file. Thus it
would be nice to just have it up front.
It would be good to be able to enable this via a standard configure
script option.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfr
put in CPPFLAGS.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
to substitute Makefile text to replace the
default rules used by Automake. This should allow changing how
Automake invokes the tool in order to pass additional arguments. Have
you tried that?
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
On Thu, 22 Mar 2018, Matěj Týč wrote:
On 21.3.2018 22:34, Bob Friesenhahn wrote:
On Wed, 21 Mar 2018, Matěj Týč wrote:
The question stands like this: Is there a demand on automake side to fix
this issue - to allow developers addressing multiple Python interpreters
of different major
no longer in use.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
I think that we should have respect for the author's dog.
Disrespecting the author's dog is not far from disrespecting the
author.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
On Wed, 24 Jan 2018, netfab wrote:
Le 24/01/18 à 14:13, Bob Friesenhahn a tapoté :
Have you made sure that the distribution tarball is packaging up this
header file?
How do I check this ? I do not have any tarball.
Make distcheck should create the tarball, and unpack it to run the
build into
2]: *** No rule to make target 'src/lib/dbus/messages/GKDBusMessage.h ',
needed by 'distdir'. Stop.
Have you made sure that the distribution tarball is packaging up this
header file?
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfrie
contracts.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
ibrary may support
multiple CRT versions but the default is the CRT version assured to
come with any Windows system, which leaves many functions out.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
is a major PITA. I did mostly succeed but there was a
Java runtime extracted from Eclipse that I never did get working
correctly given that there was no useful documentation for how to make
it work.
Please note that I am not a Java developer.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us,
On Fri, 27 Oct 2017, Warren Young wrote:
On Oct 27, 2017, at 7:19 AM, Bob Friesenhahn
wrote:
On Fri, 27 Oct 2017, Warren Young wrote:
The operating system has a database mapping what my terminal can do to a common
API. Let the library handle it.
I should point out that the "oper
are
which adds support for a terminal database.
This does not mean that it can't be supported on systems which do have
terminal information, but it makes the task somewhat more challenging.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
be
disabled with the AM_COLOR_TESTS environment variable.
Yes, and in fact I am seeing colors in my TAP test output and the
colors are readible using my current terminal background.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick
On Wed, 25 Oct 2017, Warren Young wrote:
On Oct 25, 2017, at 8:56 AM, Bob Friesenhahn
wrote:
It's also crazy that "--color-tests=y" or "--color-tests=1" won't work
While I like color in photos and nature, automatic colorization of
output often causes
ee to name it
anything you like.
If you have implemented improvements then you should submit a patch to
the Automake project.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
of the
/pub/gnu/automake directory to check upload dates and see that the
latest Automake is 1.15.1 dated June 19, 2017. This is not very old.
Does it still have the bug which is causing a problem for you?
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users
eventually move on to
Clang 3.9+.
Passing a relative path to CC seems error prone since it only applies
to the current working directory and will fail as soon as any Makefile
recurses.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick
On Fri, 7 Jul 2017, Victor Porton wrote:
I found:
all-local: ...
...
clean-local: ...
...
You can also override any rule generated by Automake with your own
rule with the same target name.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org
upport for the DESTDIR environment variable, which
specifies an alternate directory path to install into. Perhaps this
will work:
install-exec-local:
mkdir -p ${DESTDIR}${bindir}
ln -s ${DESTDIR}${pkgdatadir}/croco.php ${DESTDIR}${bindir}/croco
Bob
--
Bob Friesenhahn
bfrie...@simpl
cking
Why do compiler flags change? Did you re-run configure with different
CPPFLAGS/CFLAGS or are these flags induced on the make command line or
via environment variables?
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maint
otice that these lines all start with $(LIBTOOL). Libtool will
normally discard flags not needed for linking. It is common for
libtool to link using the C compiler when possible and so the C
compiler can also use/discard options as needed.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us,
is wise to deal with
the current behavior and make adjustments to your build processes.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Any tips? Is this at all possible?
Try adding 'make clean' to your build steps.
The best thing to do is to build outside of the source tree and use a
separate build directory for each configure incantation.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesyste
duce the same results at
different times on different machines is close to impossible.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
'make' syntax. Unless
there is a problem, you should ignore the content of Makefile.in since
it is an intermediate file.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
o the
repository, I rebuild all of the additional generated files enabled to
be updated via --enable-maintainer-mode.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
e tried to use LDADD and prog_LDADD with the same effect.
Did you mean to use LIBADD?
It may be wise to construct full paths based on Automake-provided
variables like $(top_builddir) rather than using relative paths.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems
ions based
on that. I did not even trust += syntax (due to lack of control over
order) so everything is explicit. This was ok since there were not
hundreds of subdirectories.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick
libtool as well, for cross-compiling shared libraries.
Not specifically when cross-compiling. Perl has a particular way to
name the directories in which it puts the module in the build tree and
installation tree. Part of this includes the basic architecture of
the machine (as known to Perl).
-4.0.1-x68k system?
I doubt that NetBSD is excluded.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
changes is the identity of the target, which
determines where build products go in the build tree and when
installed.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
ble solution which avoids ExtUtils::MakeMaker and
allows Automake to drive behavior, with linkage managed by libtool,
then I am all ears.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
On Tue, 30 Jun 2015, 远猷 wrote:
thanks for your reply!
but why forbidding “include” a sub-makefiles.am with absolute path?
Automake projects are expected to be self-contained and not refer to
anything outside of the package.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http
ript.
Anyhow, thanks for the heads up, I will be looking at your files. And, as
always, I am confused.
I am not surprised. :-)
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
/file/b84df92f710a/tests/common.shi
and
http://hg.code.sf.net/p/graphicsmagick/code/file/b84df92f710a/tests/rwfile.tap
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
1 - 100 of 598 matches
Mail list logo
