On 25 April 2015 at 00:04, Arthur Schwarz wrote:
>
> In 15.3.3.1 Command-line arguments for test drivers
>
> --log-file=PATH.log
>
> The .log file the test driver must create (see Basics of test metadata).
> If it has a directory component (as in e.g., sub/foo.log), the test harness
> will ens
In 15.3.3.1 Command-line arguments for test drivers
--log-file=PATH.log
The .log file the test driver must create (see Basics of test metadata).
If it has a directory component (as in e.g., sub/foo.log), the test harness
will ensure that such directory exists before the test driver is called
Hi Stefano,
Thanks for you answer. You have solved all my Autotools problems for the
time being. So it helped.
--
Met vriendelijke groeten,
Joost Kraaijeveld
Askesis B.V.
Molukkenstraat 14
6524NB Nijmegen
tel: 024-3888063 / 06-51855277
fax: 024-3608416
web: www.askesis.nl
signature.asc
Descri
On Thursday 11 November 2010, Joost Kraaijeveld wrote:
> Hi,
Hello Joost.
Sorry if I start my answer with criticism, but this subject ...
"Two questions: warning: macro `AM_CPPFLAGS' not found in library
and how to assign values?"
... already tells me that you should h
Hi,
I am getting this warning (and if I configure an error, "AM_CPPFLAGS:
command not found") for the piece of configure.ac below. What is the
correct way to achieve what I want: an incremental build up of
AM_CPPFLAGS?
And a second question: should all these assignments work
1. PLATFORM_CPPFLAG
* Jef Driesen wrote on Thu, Oct 09, 2008 at 05:26:46PM CEST:
> Ralf Wildenhues wrote:
>> * Jef Driesen wrote on Wed, Oct 08, 2008 at 10:24:46AM CEST:
>>> BTW, what is the reason that when I use mylib_la_CFLAGS =
>>> -DMYLIB_BUILD, in Makefile.am, all my object files are named
>>> "mylib_la-myfil
Ralf Wildenhues wrote:
* Jef Driesen wrote on Wed, Oct 08, 2008 at 10:24:46AM CEST:
I am shipping the symbols file. In my Makefile.am, I have
EXTRA_DIST = mylib.symbol
to make sure the file is included in the tarball.
But with this approach, msvc users will need to (manually) generate a
DEF
* Jef Driesen wrote on Wed, Oct 08, 2008 at 10:24:46AM CEST:
>
> I am shipping the symbols file. In my Makefile.am, I have
>
> EXTRA_DIST = mylib.symbol
>
> to make sure the file is included in the tarball.
>
> But with this approach, msvc users will need to (manually) generate a
> DEF file from
Ralf Wildenhues wrote:
* Jef Driesen wrote on Thu, Oct 02, 2008 at 05:08:55PM CEST:
mylib.exp: mylib.symbols
if XYZ
$(CPP) -P -DMYLIB_XYZ_SUPPORT - < mylib.symbols | sed -e '/^$$/d' > $@
else
$(CPP) -P - < mylib.symbols | sed -e '/^$$/d' > $@
endif
CLEANFILES = mylib.exp
EXTRA_DIST = mylib.
* Jef Driesen wrote on Thu, Oct 02, 2008 at 05:08:55PM CEST:
>
> mylib.exp: mylib.symbols
> if XYZ
> $(CPP) -P -DMYLIB_XYZ_SUPPORT - < mylib.symbols | sed -e '/^$$/d' > $@
> else
> $(CPP) -P - < mylib.symbols | sed -e '/^$$/d' > $@
> endif
>
> CLEANFILES = mylib.exp
> EXTRA_DIST = mylib.symbol
Ralf Wildenhues wrote:
Hello Jef,
* Jef Driesen wrote on Tue, Sep 23, 2008 at 08:44:47PM CEST:
Brian Dessent wrote:
There are two aspects to the symbol visibility stuff:
[ snip nice explanation ]
Now that I start to understand all the differences, I only need to find
a way how to incorpora
Hello Jef,
* Jef Driesen wrote on Tue, Sep 23, 2008 at 08:44:47PM CEST:
> Brian Dessent wrote:
>> There are two aspects to the symbol visibility stuff:
[ snip nice explanation ]
> Now that I start to understand all the differences, I only need to find
> a way how to incorporate everything nicel
Brian Dessent wrote:
Jef Driesen wrote:
And how about gcc < 4.0 that do not support the visibility attributes?
Is there a way to hide non-public symbols? Is the version script still
available in this case? Is it possible to use both the attributes and
the -export-symbols together?
There are t
Jef Driesen wrote:
> And how about gcc < 4.0 that do not support the visibility attributes?
> Is there a way to hide non-public symbols? Is the version script still
> available in this case? Is it possible to use both the attributes and
> the -export-symbols together?
There are two aspects to the
Brian Dessent wrote:
Jef Driesen wrote:
The MSDN documentation [1] about this issue, gives me the impression
that applications have to relink when new symbols are added to the
library (when not using a DEF). And that's something I would like to
avoid. Actually this statement surprises me, so I'
* Brian Dessent wrote on Fri, Sep 19, 2008 at 05:18:08PM CEST:
> Jef Driesen wrote:
>
> > The preprocessor stuff is automated. I only have to maintain a symbols
> > file with a few #ifdef's in it:
> >
> > mylib_abc
> > #ifdef MYLIB_XYZ_SUPPORT
> > mylib_xyz
> > #endif
>
> But it's still two
Jef Driesen wrote:
> The MSDN documentation [1] about this issue, gives me the impression
> that applications have to relink when new symbols are added to the
> library (when not using a DEF). And that's something I would like to
> avoid. Actually this statement surprises me, so I'm probably just
Brian Dessent wrote:
Jef Driesen wrote:
What are the (dis)advantages of each method? I see differences in usage
(see below), but are there technical differences as well?
It sounds like you already are aware of all the tradeoffs. I don't
think there's a technical difference in the end, i.e. t
Jef Driesen wrote:
> What are the (dis)advantages of each method? I see differences in usage
> (see below), but are there technical differences as well?
It sounds like you already are aware of all the tradeoffs. I don't
think there's a technical difference in the end, i.e. the results are
the sa
I have a cross platform (win32/unix) project that consist of a C library
and a few example applications using that library. The entire project is
build with autotools. With the instructions from the online autotools
book [1], I managed to build both a Windows DLL and a Unix shared
library. But
* NightStrike wrote on Wed, Mar 19, 2008 at 07:02:17PM CET:
> On 3/11/08, Bob Friesenhahn <[EMAIL PROTECTED]> wrote:
> > On Tue, 11 Mar 2008, NightStrike wrote:
> > >
> > > I had intended to do everything with non-recursive make, but as you
> > > pointed out once, non-recursive is also considered h
Hi,
On Wed, Mar 19, 2008 at 03:55:55PM -0400, NightStrike wrote:
> > mingw-w64/crt
> > mingw-w64/doc
> > mingw-w64/hdr
...
> So I guess the choices boil down to:
>
> 1) Change the directory structure
> 2) Recursive make to a small degree
>
> Is that about right?
actually, I recommend recursive
On 3/19/08, Stepan Kasal <[EMAIL PROTECTED]> wrote:
> Hello,
>
> On Wed, Mar 19, 2008 at 03:13:06PM -0400, NightStrike wrote:
> > On 3/19/08, Stepan Kasal <[EMAIL PROTECTED]> wrote:
> > > BTW: Why do you insist on the layout described above? I would have
> > > one top-level directory and make "doc
Hello,
On Wed, Mar 19, 2008 at 03:13:06PM -0400, NightStrike wrote:
> On 3/19/08, Stepan Kasal <[EMAIL PROTECTED]> wrote:
> > BTW: Why do you insist on the layout described above? I would have
> > one top-level directory and make "doc" and "headers" (or perhaps
> > "hdr") subdirs.
>
> The mingw-
On 3/19/08, Stepan Kasal <[EMAIL PROTECTED]> wrote:
> BTW: Why do you insist on the layout described above? I would have
> one top-level directory and make "doc" and "headers" (or perhaps
> "hdr") subdirs.
The mingw-w64-headers directory contains headers that are required to
use the resulting gcc
Good afternon Della,
On Wed, Mar 19, 2008 at 02:02:17PM -0400, NightStrike wrote:
> > On Tue, 11 Mar 2008, NightStrike wrote:
> > > I had intended to do everything with non-recursive make, but as [Ralf]
> > > pointed out once, non-recursive is also considered harmful.
[thread:]
> http://lists.gnu.
On 3/11/08, Bob Friesenhahn <[EMAIL PROTECTED]> wrote:
> On Tue, 11 Mar 2008, NightStrike wrote:
> >
> > I think I understand what you mean. Create a recursive build tree
> > that allows starting from any point. I would then perhaps put this
> > also in the trunk/Makefile.am:
> >
> > EXTRA_DIST=m
On 3/11/08, Bob Friesenhahn <[EMAIL PROTECTED]> wrote:
> On Tue, 11 Mar 2008, NightStrike wrote:
> >
> > I think I understand what you mean. Create a recursive build tree
> > that allows starting from any point. I would then perhaps put this
> > also in the trunk/Makefile.am:
> >
> > EXTRA_DIST=m
On Tue, 11 Mar 2008, NightStrike wrote:
I think I understand what you mean. Create a recursive build tree
that allows starting from any point. I would then perhaps put this
also in the trunk/Makefile.am:
EXTRA_DIST=mingw-w64-headers mingw-w64-doc
So that from the trunk directory, I could run
On Tue, Mar 11, 2008 at 5:41 PM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * NightStrike wrote on Mon, Mar 10, 2008 at 03:42:52PM CET:
>
> > Our project is laid out like this:
> >
> > /trunk/
> > /trunk/mingw-w64-crt/
> > /trunk/mingw-w64-doc/
> > /trunk/mingw-w64-headers/
>
>
> > What is t
* NightStrike wrote on Mon, Mar 10, 2008 at 03:42:52PM CET:
> Our project is laid out like this:
>
> /trunk/
> /trunk/mingw-w64-crt/
> /trunk/mingw-w64-doc/
> /trunk/mingw-w64-headers/
> What is the best way to handle this situation to remove the need to
> manually tar up the trunk?
Move the (to
Project page: http://sourceforge.net/projects/mingw-w64
Our project is laid out like this:
/trunk/
/trunk/mingw-w64-crt/
/trunk/mingw-w64-doc/
/trunk/mingw-w64-headers/
In the *-crt directory is where the build system resides, including
any headers required to *build* the crt. In the *headers d
Am Sonntag, den 11.02.2007, 23:24 -0300 schrieb Matías Alejandro
Torres:
[..]
> I figure out my two questions... almost, let's say I want to copy one
> whole directory recursively
>
> Makefile.am
>
> contactsdatadir = ${prefix}/share/applications/contacts
> contacts
have a couple of questions,
1- how do i set up a PREFIX macro so i know where the program is going
to be installed after executing ./configure? (accesible from my code).
2- What about if I want to install images when make install is
executed? where I configure that?
Thanks, Matias.
I f
Hi all
I'm using anjuta for generating the configure, make and make install
needed files for a program of my own. After doing these i discover
that... it configures and builds okey, it even checks for the needed
libraries. Great so far.
Anyway .. I have a couple of questions,
1- how
>>> "Martin" == Martin MAURER <[EMAIL PROTECTED]> writes:
[...]
Martin> I thought about a noinst library, and this might be an option.
It is.
Martin> what i would like to have is a configure file in the
Martin> toplevel directory, which then checks the dependencies
Martin> for all the clie
Hello all,
I am developing a project (http://fireflier.sf.net), which uses
automake. I don't know a lot about automake, and so far i didnt find
documentation, which helps me with my problem - so any pointers in the
correct direction will be appreciated.
fireflier is a interactive firewall system w
>>> "Steven" == Steven Eker <[EMAIL PROTECTED]> writes:
Steven> I'm converting a large program to autoconf/automake and I've run into
Steven> a number of problems:
Steven> (1) How do I ensure a particular file gets recompiled everytime (just
Steven> before) a program is linked (say to update
I'm converting a large program to autoconf/automake and I've run into
a number of problems:
(1) How do I ensure a particular file gets recompiled everytime (just
before) a program is linked (say to update the build time via
__DATE__ and __TIME__)? Previously I just put this before the link
Jose Roman Bilbao <[EMAIL PROTECTED]> writes:
> 1st: I have a multiple subdirectories project. One of those directories
> stores again multiple subdirectories. In each of them a librtary
> (shared) is built and stored in .lib (local) directory. Te thing is that
> I would like all my libraries to be
Thank you for correcting me.
with regards,
Santosh.
On Tue, 17 Jun 2003, Raja R Harinath wrote:
> Hi,
>
> Santosh <[EMAIL PROTECTED]> writes:
>
> > For the second question, you can use the $(top_srcdir)
> > variable and give the complete path of your library.
> >
> > example:
> > 2Dint
Hi,
Santosh <[EMAIL PROTECTED]> writes:
> For the second question, you can use the $(top_srcdir)
> variable and give the complete path of your library.
>
> example:
> 2Dinterpolation_LDADD =
> $(GLIB_CFLAGS) \
> $(top_srcdir)/src/errors/libErrors.a \
> $(
regards,
Santosh.
On 17 Jun 2003, Jose Roman Bilbao wrote:
> Hi,
>
> I am finally reaching the end of my "autotoolization" of my program but
> I still have two questions I think will be easy to solve but I can not
> figure out how to do it...
>
> 1st: I have a multi
Hi,
I am finally reaching the end of my "autotoolization" of my program but
I still have two questions I think will be easy to solve but I can not
figure out how to do it...
1st: I have a multiple subdirectories project. One of those directories
stores again multiple subdirectories.
Repost on one of the questions I formerly asked (and did not find the
answer to in the [wonderful] book [that I have spent the last 2 days
reading cover-to-cover :-)] @
http://sources.redhat.com/autobook/autobook/autobook_toc.html#SEC_Contents
Here's the repost:
3. I get a Makefile, run mak
Hi all
I just became maintainer of a rather large-scale cross-platform project.
Our configure/makefiles are written somewhat awkwardly and
self-implemented, and after some deliberation and study, We decided to port
to autoconf/automake.
1. I am currently experimenting on a stock x86 RH7.2, and re
p_builddir)/.libs:.libs" >> test1.sh
@echo "./test" >> test1.sh
@chmod +x test1.sh
Now the questions:
1. if I use lib_LTLIBRARIES, then libTestAction.so is created, but also
installed if I call make install, if I use check_LTLIBRARIES or
noinst_LTLIBRARI
> ">" == mallum <[EMAIL PROTECTED]> writes:
>> I've a project that builds a number of binarys, 1 of which should
>> only be built if apm.h is found.
>> In configure.ac, I have;
>> AC_CHECK_HEADERS(apm.h,APMLIB="-lapm",APMLIB=)
>> and in my Makefile.am I have;
>> if @APMLIB@
>> APM_PROGS =
Hi;
I've a project that builds a number of binarys, 1 of which should only
be built if apm.h is found.
In configure.ac, I have;
AC_CHECK_HEADERS(apm.h,APMLIB="-lapm",APMLIB=)
and in my Makefile.am I have;
if @APMLIB@
APM_PROGS = miniapm
endif
bin_PROGRAMS = minitime monolaunch mbcontrol $(
Hi,
Thanks for your reply...
> Thomas> So we started shipping .m4 files from these libraries
> Thomas> in a separate m4 directory.
>
> ... and whenever you make a new release you will have to make
> sure those fallback macros have not been used accidentally?
Well, it's easy to see that they'
>>> "Thomas" == Thomas Vander Stichele <[EMAIL PROTECTED]> writes:
[...]
Thomas> In most cases you use the .m4 macro installed with the
Thomas> -devel package of the library. Since we cannot expect
Thomas> every GStreamer developer to have all libraries and
Thomas> -devel packages that coul
Hi,
I've recently gotten more involved with autoconf and automake because I
cleaned up build issues for GStreamer, a multimedia framework. I'm rather
new to autotools so I probably make a lot of mistakes along the way.
Anyway, I first have some questions on "the right thing to
cool! Thanks for the help.
-Dan
On Fri, 12 Oct 2001, Raja R Harinath wrote:
> Hi,
>
> Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
> "mcmahill" == mcmahill <[EMAIL PROTECTED]> writes:
> > mcmahill> 1) How can I specify a different directory or
> > mcmahill> subdirectory for a p
Hi,
Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
"mcmahill" == mcmahill <[EMAIL PROTECTED]> writes:
> mcmahill> 1) How can I specify a different directory or
> mcmahill> subdirectory for a program? The application is a cgi
> mcmahill> program which might, for example, end up in
> m
>>> "mcmahill" == mcmahill <[EMAIL PROTECTED]> writes:
[...]
mcmahill> 1) How can I specify a different directory or
mcmahill> subdirectory for a program? The application is a cgi
mcmahill> program which might, for example, end up in
mcmahill> /usr/local/libexec/cgi-bin. The standard thin
On Wed, 10 Oct 2001 [EMAIL PROTECTED] wrote:
>
>
> Hi,
>
> I've recently converted a project over to automake and have several
> questions.
>
>
> 1) How can I specify a different directory or subdirectory for a program?
> The application is a cgi pr
Hi,
I've recently converted a project over to automake and have several
questions.
1) How can I specify a different directory or subdirectory for a program?
The application is a cgi program which might, for example, end up in
/usr/local/libexec/cgi-bin. The standard things
> David> Am I doing the right thing by specifying `LDADD =
> David> ../src/.libs/libpdl.a'.
>
> Nope. Doesn't it work to use `../src/libpdl.la'?
oh wow, i didn't even try that. ../src/libpdl.la is a text file and i
didn't think that would work. but it does. and the actual compile
line seems
> "David" == David Petrou <[EMAIL PROTECTED]> writes:
David> Am I doing the right thing by specifying `LDADD =
David> ../src/.libs/libpdl.a'.
Nope. Doesn't it work to use `../src/libpdl.la'?
David> 2. I've noticed that there's no target to make an html version
David> of a texinfo file. I
Hi. I have a few unrelated questions regarding automake.
1. I'm maintaining a library that uses automake. After building my
library, I have test programs that run via `make check' to confirm
that everything's working properly. These programs need to link into
the built (bu
On Wednesday 16 May 2001 5:26 am, Tom Tromey wrote:
> > "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
> >>
> >> I'm not sure about the cvs automake. I'll write a test.
>
> Gary> Neither CVS or 1.4-p1 do this by default. I developed a habit
> Gary> of adding `MAINTAINERCLEANFILES += M
On May 16, 2001, Reinhard Müller <[EMAIL PROTECTED]> wrote:
> Tom Tromey wrote:
>> According to my test, at least cvs automake does remove Makefile.in on
>> `maintainer-clean'.
>>
>> It does not remove aclocal.m4 or configure, though. It should. My
>> test will ensure that we (eventually) fix
Tom Tromey wrote:
> According to my test, at least cvs automake does remove Makefile.in on
> `maintainer-clean'.
>
> It does not remove aclocal.m4 or configure, though. It should. My
> test will ensure that we (eventually) fix this.
Let me add config.guess, config.sub, ltconfig, ltmain.sh, con
> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
>> I'm not sure about the cvs automake. I'll write a test.
Gary> Neither CVS or 1.4-p1 do this by default. I developed a habit
Gary> of adding `MAINTAINERCLEANFILES += Makefile.in' to all of my
Gary> Makefile.am's and never thought to
On Tuesday 15 May 2001 11:19 pm, Tom Tromey wrote:
> > "Reinhard" == Reinhard Mller <[EMAIL PROTECTED]> writes:
>
> Reinhard> A quick hint where to look how to make sure i'm using gcc?
>
> Read the description of AC_PROG_CC in the autoconf manual.
>
> >> It should be. What version of automake
> On Tue, 15 May 2001 21:40:59 +0200, Reinhard =?iso-8859-1?Q?M=FCller?=
><[EMAIL PROTECTED]> said:
> Hi! * What is the proper way of adding -Wall to the gcc options? *
Check out the macro ac_compile_warnings.m4 at the autoconf archive
site
http://cryp.to/autoconf-archive/
> "Reinhard" == Reinhard Müller <[EMAIL PROTECTED]> writes:
Reinhard> A quick hint where to look how to make sure i'm using gcc?
Read the description of AC_PROG_CC in the autoconf manual.
>> It should be. What version of automake are you using?
Reinhard> It is not. I'm using automake 1.4,
Tom Tromey wrote:
>
> > "Reinhard" == Reinhard Müller <[EMAIL PROTECTED]> writes:
>
> Reinhard> * What is the proper way of adding -Wall to the gcc options?
>
> It depends.
>
> If you know you'll only ever use gcc then you can put it in AM_CFLAGS.
> You could do this in configure.in and us
> "Reinhard" == Reinhard Müller <[EMAIL PROTECTED]> writes:
Reinhard> * What is the proper way of adding -Wall to the gcc options?
It depends.
If you know you'll only ever use gcc then you can put it in AM_CFLAGS.
You could do this in configure.in and use AC_SUBST or you could put it
in eac
Hi!
* What is the proper way of adding -Wall to the gcc options?
* Why isn't Makefile.in cleaned with make maintainer-clean?
Thanks a lot and sorry if this has been asked before,
--
Reinhard Müller
GNU Enterprise project
> "David" == Masterson, David <[EMAIL PROTECTED]> writes:
David> * Does Automake assume that Info files should be part of the
David> distribution of a package (ie. "make dist")?
Yes.
David> ** If so, why?
GNU coding standards
David> ** Is there a means to specify that Info files should *n
I've been converting CFEngine to use Automake and have run into a few
questions that I would like to get answered:
* Does Automake assume that Info files should be part of the distribution of
a package (ie. "make dist")?
** If so, why?
** Is there a means to specify that Info fi
72 matches
Mail list logo
