On Sun, 27 Sep 2009, Ty Tower wrote:
I have avrdude 5.5 installed on my machine running Mandriva 2009
I have been trying to install 5.8 and get this error below which seems to be
the ylwrap script but it is too complex for
me to sort
Can someone tell me if this is a bug or my error
...
Refactor Automake so it can easily be extended for new file types.
Examples:
- Qt preprocessed files (e.g. moc and linguist generate sources to link)
- IDL files (may generate headers and several sources to link)
- NVidia's CUDA
Automake has many rules baked in; there is no clear extension
On Fri, 11 Mar 2011, Ralf Wildenhues wrote:
* Roger Leigh wrote on Thu, Mar 10, 2011 at 01:03:16PM CET:
This is not meant to sound like a troll, but: is anyone really
*really* using static linking in 2011?
I'd love to answer no, but at least parts of the HPC crowd will do
almost anything to
On Sun, 20 Mar 2011, Ralf Wildenhues wrote:
Or add a subunit parser and a quick tap2subunit perl module today
and have the best of both worlds? (This is meant as an honest question,
even if it looks like a rhetoric one.)
I think that's a good approach. I don't really use either framework,
On Tue, 5 Apr 2011, Dave Hart wrote:
On Mon, Apr 4, 2011 at 22:15 PM, Martin Hicks m...@bork.org wrote:
Is there a way to specify a different compiler for compile-time helper
programs that are used during the build of a package?
I think the short answer is no. I have some source files in a
On Sun, 15 May 2011, Vincent Torri wrote:
in a Makefile.am that is in the $(top_builddir)/path1/path3 directory, the
library uses a file that is in the $(top_builddir)/path1/path2 directory.
Is it better to use absolute path:
mylib_SOURCES = $(top_builddir)/path1/path2/file.c
or relative path
FYI, when I install a new version of the autotools, I do something like
# PATH=/new/path/bin:$PATH
# cd m4; ./configure --prefix=/new/path; make; make install
# cd ../autoconf; ./configure --prefix=/new/path; make; make install
# cd ../automake; ./configure --prefix=/new/path; make; make install
On Mon, 23 May 2011, Daniel Herring wrote:
FYI, when I install a new version of the autotools, I do something like
# PATH=/new/path/bin:$PATH
# cd m4; ./configure --prefix=/new/path; make; make install
# cd ../autoconf; ./configure --prefix=/new/path; make; make install
# cd ../automake
On Mon, 15 Aug 2011, Misha Aizatulin wrote:
I would like to use variables in the definition of SUBDIRS, something
of the kind:
DEPS = $(TOP)/deps
CIL = $(DEPS)/cil-1.3.7
SUBDIRS = $(CIL) ...
Would one of these help?
On Sun, 1 Jan 2012, Stefano Lattarini wrote:
On 12/31/2011 12:29 AM, Jan Engelhardt wrote:
I have seen user-induced lines in Makefile.am like these in a handful
of packages:
...
${pkgconfig_DATA}: ${top_builddir}/config.status
Given that automake 1.11.1/autoconf 2.68 seem to
On Mon, 29 Oct 2012, The_Jav wrote:
I would like to create an if condition. But it works partially :
libmy_lib_SOURCES = source.c
if HAVE_IPP
libmy_lib_SOURCES += ipp.c
endif
when the HAVE_IPP is false, the makefile created is different than a
makefile created with only libmy_lib_SOURCES =
On Tue, 1 Jan 2013, Stefano Lattarini wrote:
OTOH, what about distribution tarballs in '.zip' format? They don't
use tar at all ... Time to deprecate them maybe? Is anybody actually
using them? And while at it, what about the even more obscure 'shar'
format?
While I haven't manipulated a
On Mon, 28 Jan 2013, Stefano Lattarini wrote:
Feedback, opinions, objections?
There was a lot to read, and I confess to not giving it full justice.
Others have already extolled the virtues of backwards compatibility.
Regarding some why questions, here's the manual entry on how versioning
I like the -alpha/-beta/-rcN markings. As someone who often tracks
cutting-edge stuff, it is nice to have a clear indicator of how stable the
author things something is. This info helps the user do a quick
cost/benefit estimate when deciding what version to use today.
- Daniel
Hi Michal,
I've always handled this by distributing the single real file, along with
a script that creates missing symlinks later, either during configure or
as part of one of the make targets.
Its a bit quirky, but not too annoying. Since the dist target is for
making source packages,
+1 for Diab's book and parser recommendations. Here are two more links to
them.
http://modernperlbooks.com/books/modern_perl_2014/07-object-oriented-perl.html
https://jeffreykegler.github.io/Marpa-web-site/
If you like historical perspective, then here's an interesting read.
Hi,
Regarding the topic of colored TAP output, it seems that there are good
reasons for having both plain-text and colored-text output. There are
also reasons for people to customize the colors.
Here are two ideas that might help. For all I know, the code may already
be structured this
I would use or copy the definition in GNU Autoconf. Portable and battle
tested. You can dig through their macros or look in a configure script to
see how they generate abs_builddir, abs_srcdir, abs_top_builddir, ...
- Daniel
On Fri, 9 Oct 2020, Cristian Morales Vega wrote:
I would like
Hi Jacob,
It seems fragile for DejaGnu to probe for a testsuite directory and change
its behavior as you describe. For example, I could have a project without
the testsuite dir, invoke the tester, and have it find and run some
unrelated files in the parent directory. Unexpected behavior
Hi Billa,
It sounds like you are trying to build from a source repo instead of a
release tarball.
Building with automake or autoconf is a multi-step process. Run automake
on a ".am" file to generate a makefile. Run make on the makefile to build
the executable.
Automake has a special
Hi Mike,
It often makes sense to change a project that uses Autotools rather than
modifying the Autotools. Can this argument-splitting behavior be
documented as expected? Are no workarounds available?
Replacing "overly fancy but proven shell script" with "dependency on a new
tool" may
On Tue, 15 Feb 2022, Jan Engelhardt wrote:
On Tuesday 2022-02-15 07:16, Daniel Herring wrote:
Maybe a next-generation configuration tool should start by defining interfaces
for user interactions and build tools. This would allow CLI and easy GUI and
IDE users, integration with multiple
On Mon, 28 Jan 2013, Stefano Lattarini wrote:
Feedback, opinions, objections?
There was a lot to read, and I confess to not giving it full justice.
Others have already extolled the virtues of backwards compatibility.
Regarding some why questions, here's the manual entry on how versioning
23 matches
Mail list logo
