On 2008-04-11 16:28, John Calcote wrote:
Stefan,
I asked this very question a few years ago on this list.
Interestingly, my examples came not from the Linux kernel build
process, but from Windows builds, which use a similar output format. I
love this format because warnings and errors are obviou
Tim Van Holder wrote:
> Something like this perhaps (should also work in cases where "$(CC) -E"
> is not equivalent to "$(CPP)"):
>
> .i.cpp:
> $(CPP) $(CPPFLAGS) -o $@ $<
>
> noinst_DATA: Quadratic.i
Of course I meant:
# Not sure if this is
Alan Larkin wrote:
> I cant figure out how to write a Makefile.am which directs that a %.cpp
> be preprocessed to a %.i (and not compiled). Anybody got a suggestion?
>
> Something like:
>
> AM_CPPFLAGS = -I$(top_srcdir)/src @INCLTDL@
> bin_PROGRAMS = Quadratic
> Quadratic_SOURCES = Quadratic.cpp
Tim Van Holder wrote:
> Given that the "programs" are basically incarnations of a test script
> and not binary executables, would it make sense to use check_SCRIPTS
> instead of check_PROGRAMS?
Ignore this - it's early in the morning, just reread the message to find
Benoit Sigoure wrote:
> Hello
> My make distcheck fails on Windows because of the following:
>
> -
> check_PROGRAMS = \
> simple \
> xml-simple \
> parentness
Ryan McDougall wrote:
> should I understand that (for example) when redhat/debian build lets say
> libc for packaging as a binary, they download a tarball and do a
> complicated form
> './configure --prefix=/usr && make && make install' on a bare machine
> without any libc, then tar up the result
Paulo Jorge Matos wrote:
> Hi all,
>
> I wish to distribute a directory with a lot of subdirectories with my
> project. I have:
> project
> - bench
> - src
>
> the src is being distributed already since it contains sources but
> the bench directory contains a bunch of text files which sh
Bruno Haible wrote:
>>> - Target "install" should install foobar.dll into $(libdir), using
>>>$(INSTALL_DATA).
>>
>>May any post-install action be necessary for the library (on some hosts)?
>
> None that I'm aware of.
Well on windows hosts (and possibly hosts with sscli), there is the
possib
Bruno Haible wrote:
> Simon Josefsson wrote:
>
>>> - Target "clean" should remove foobar.dll.
>>
>>Adding '-g' make the Mono compiler create files called foo.dll.mdb.
>>So the "clean" target should probably remove them too.
>
>
> I agree. Target "clean" should remove foobar.dll and foobar.dll.m
Bruno Haible wrote:
>Implementation | Compiler
>---+-
>pnet | cscc
>mono | mcs
>sscli | csc
On Windows, it's the .NET SDK, and csc is the compiler.
If you're going to add support for C#, you should include its main
source platfor
Ralf Wildenhues wrote:
> Hi David, Warren.
>
> * Warren Young wrote on Fri, Nov 04, 2005 at 01:49:42AM CET:
>
>>David Byron wrote:
>>
>>>What I'm having trouble with is getting the builddate.c recipe to happen
>>>at the right time.
>>
>>Could you make it depend on *.o except for builddate.o? I
Mailing Lists wrote:
Thanks Tim.
However, I don't really know what to do with the above error message, and what
the next debugging step could/should be.
You could try using a different Perl (e.g. the ActiveState one instead
of the Cygwin one). Or you could just try turning the configure.ac
into U
Mailing Lists wrote:
Hi all!
I am trying to compile some software (VLC from the VideoLAN project) on W2K/CygWin.
Unfortunately, during the config, I get an
error. I have already contacet the VideoLAN malining list, but to no avail. I will
also contact the CygWin mailing list, but for the
time be
JRBCAST wrote:
Hi,
I have been trying to disable the -g flag that autoconf uses when
compiling my GNU project. I have tried --enable-debug=no --disable-debug
and none works. I have had a look at google and some questions but no
response...
Can you help me?
my configure.ac is:
All the next just c
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 nice that after removing a file, it
) > removes all the empty
user will manually edit the stamp file, so this should generally do
the right thing - i.e. rerun foo if data.foo changes, and ignore
timestamp changes on the outputs.
But there are probably reasons not to use stamp files.
> On Thu, Feb 05, 2004 at 08:25:52AM +0100, Tim Van Holder wrote:
> >
> >What we need is a rule that forces a rebuild when data.h
> is missing.
> >
> > data.c: data.foo
> > foo data.foo
> > data.h: data.c
> > @if test -f $@; then :; else \
> >rm -f data.c; \
> >$(MAKE) $(AM_MAKEFLAGS) data.c; \
> >>> "Tim" == Tim Van Holder <[EMAIL PROTECTED]> writes:
>
> [...]
>
> Tim> It currently isn't; --enable-shared --disable-static
> still builds
> Tim> static libraries. There's a thread on the libtool
> mailing list
> > Norman> Also, note that if you include the declarations
> for building a shared
> > Norman> library, automake will automatically build the
> corresponding static
> > Norman> library [this is true, isn't it?]
> >
> > Honestly I don't know. Perhaps it's true, I guess it is, but
> > even
> platform dependent parts present in the ".libs" subdirectory.
(or "_libs" on platforms where filenames cannot start with a '.')
> Version info:
> aclocal 1.5
> automake 1.5
You may want to consider upgrading to automake 1.7.6 (I think that's
the latest version).
If that does not resolve your problem (and your remarks), at least
we'll know it's a current problem.
Mainly a few minor language nits; I'm not a native English speaker either,
so feel free to correct me if my "feel" is off.
> Building shared libraries is a relatively complex matter. For this
Maybe make this 'Portably building shared libraries...' - if portability
isn't an issue, building shared
> Query 2:
> I have a GUI module, I make it a library.
> I have a communication module which responds to
> requests from GUI module and does communication.
> This again is made a library.
> Now you have
> GUI -> communication
> The comm. library may
> receive requests from other users and it
> If I have something like this in my configure.ac:
>
> AC_PATH_PROG(SED, sed)
> AC_ARG_VAR(SED, [path to sed])
>
> Now everything works fine when sed is in my PATH, but I would like for
> ./configure to fail if sed isn't in my PATH. Is there a
> standard way to do
> this? I haven't found any.
>
On Thu, 2002-11-07 at 12:57, Alexandre Duret-Lutz wrote:
> >>> "Tim" == Tim Van Holder <[EMAIL PROTECTED]> writes:
>
> Tim> On Wed, 2002-11-06 at 11:11, [EMAIL PROTECTED] wrote:
> >> DEFAULT_INCLUDES = -I. -I$(srcdir) -I.
> >>
> &
ot;" merely searches '.' first, then searches along the
include path normally. Once you start relying on the include path, you
should really be using <> instead of quotes for your #include.
For one thing, using "" will cause any header of the same name in the
current dir to be used in preference of one in the include path.
--
Tim Van Holder <[EMAIL PROTECTED]>
Anubex
On Fri, 2002-09-06 at 13:37, Ronald Landheer wrote:
> Hello all,
>
> I'm trying to bootstrap a package that is "almost" completely compliant with the GNU
>coding standards: the only difference with a normal GNU pack is that the README file
>is generated (from a perlpod file). This is meant to m
> any reason to hold it? Please, unleash the beast!
Just one (possibly minor) problem: the yacc rules
hard-code .tab.* as the output root, while DOSish
systems use _tab.* (cfr LEX_OUTPUT_ROOT).
This will make automake's yacc rules unusable in
non-LFN environments.
In itself not a big deal, I su
On Thu, 2002-02-28 at 17:13, Pavel Roskin wrote:
> Hello!
>
> Could anybody please check what's going on with Automake CVS? If I'm
> using anonymous CVS (:pserver:[EMAIL PROTECTED]:/cvs/automake) it
> almost always fails:
>
> $ cvs up
> Fatal error, aborting.
> load average of 25 is too high
On Fri, 2002-02-22 at 03:23, Fausto Sanchez wrote:
> Hi,
>
> Can anyone tell me how to suppress these warning from automake. I just upgraded
> to automake 1.5, and now these warnings are being displayed when running
> automake.
>
> diag_LDADD = @LDFLAGS@ -L../common_objects -ldiagcommonobj -ldi
On Thu, 2002-01-31 at 16:50, Tim Van Holder wrote:
> You didn't translate correctly.
> The CVS version of the above is:
>
> AC_INIT([libXrc], [0.1], [libXrc])
> AM_INIT_AUTOMAKE
>
> By omitting the thrid arg to AC_INIT, you basically said 'I want the
> ta
On Thu, 2002-01-31 at 16:21, Ralf Corsepius wrote:
> Given an autoconf-2.52 and automake-1.5 compatible configure.in:
> ..
> AC_INIT
> ..
> AM_INIT_AUTOMAKE(libXrc, 0.1)
> ..
>
> make dist produces libXrc-0.1.tar.gz, PACKAGE is set to libXrc.
>
> With autoconf-cvs and automake-cvs, now using the
On Tue, 2002-01-15 at 22:38, Ted Irons wrote:
> Just a thought ...
Might as well put in my .02 Euro as well.
I kinda like a gcc-style approach; i.e. install the actual automake/...
scripts as $prefix/share/automake/version/automake. Then have a
$prefix/bin/automake that checks for some option t
Something like this, perhaps?
2001-10-21 Tim Van Holder <[EMAIL PROTECTED]>
* doc/autoconf.texi: Mention the issue of bash 2.05's
`set' builtin.
Index: doc/autoconf.texi
===
RCS file: /
> >> > it is probably still worth mentioning in the autoconf manual's
> >> > section on portable shell programming.
> >>
> >> Yes, that makes sense.
>
> Tim> I'll whip up something tomorrow.
>
> Hi Tim! ;)
Hi Akim!
As you well know, time is a relative concept (in fact, to me it's
yesterday at
> IDLFLAGS = flags to pass to compiler (default -bcxx -Wbh=.h -Wbs=.cpp)
Here, and in the rest of your patch, you hardcode the assumption that
a) you're targetting C++; while this is very likely, I assume other
output languages are possible too (Java maybe?)
b) the extension desired for C
> Well this first way didn't work:
> automake (I had to use an old 1.4... but I think this doesn't
> change the thing)
I think it might. I know 1.5 is much better at conditional stuff.
But you could be right.
> > TASKOBJ=wtask.$OBJEXT # or TASKOBJ='wtask.$(OBJEXT)'; your choice
> at this poin
On Tue, 2001-10-02 at 15:17, Matthias Braun wrote:
> Hello,
>
> I'm quite new to automake so I don't know if the following is a bug or an error from
>me:
>
> I use the following Makefile.am:
> ---
> EXTRA_libsal_la_SOURCES=wtask.cxx
> if USE_WINTASK
> TASKSOURCES=wtask.cxx
> endif
>
> EXTRA_l
> > Suffice it to say that I believe that CVS is the wrong tool
> for this.
> > Most, if not all, of the other projects with which I am
> familiar agree
> > with me. Autoconf and automake are the two glaring
> counter-examples,
> > so I wondered if they knew something that I didn't.
>
>
Please, no HTML.
> lib_LTLIBRARIES = libfoo.la
> libfoo_la_SOURCES = \
> one.c \
> one.cpp \
> two.c \
> two.cpp
IIRC, Automake 1.5 supports subdirectories; using
lib_LTLIBRARIES = libfoo.la
libfoo_la_SOURCES = \
c/one.c \
cpp/one.cpp \
c/two.c \
cpp/t
> Why is this broken?
I was only relaying a problem someone else reported; it seemed odd
to me, but without 2.05 lying around, I couldn't test it.
> It's true that you can't parse the latter line with other shells.
> So perhaps what you're saying is that, if you use Bash 2.05 to
> run 'configure
I asked about this a whil ago, but since I didn't receive any
comments, I'm asking again.
bash's behaviour with regards to the 'set' builtin has changed
in 2.05:
> 3. New Features in Bash
>
> b. When `set' is called without options, it prints function
> defintions in a way that allows the
> I really like the autogen.sh file that comes with most GNOME
> programs, and
> steal it for many of my own programs. This sort of thing is
> quite useful
> for people using tools like automake and autoconf.
>
> Has there been any consideration of putting together a
> "standard" autogen.sh sc
> AC_INIT_AUTOMAKE(hello,0)
Should be AM_INIT_AUTOMAKE. That is not new to automake-cvs.
> AC_PROG_CC
> AC_CONFIG_FILES([Makefile])
> AC_OUTPUT
> automake: Makefile.am: required file `./NEWS' not found
> automake: Makefile.am: required file `./README' not found
> automake: Makefile.am: required
On 11 Jun 2001 21:29:01 -0600, Tom Tromey wrote:
>
> Or you could just punt and go back to using an @...@ substitution in
> _LDADD. Ugh.
I was afraid of that. Sigh.
Thanks anyway.
--
Tim Van Holder - Anubex N.V.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
ing functionality was broken/nonexistent up
until a few weeks ago.
Thanks for the suggestion though.
--
Tim Van Holder - Anubex N.V.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
This message was posted using plain text. I do not endorse any
products or services that may be hyperlinked to this message.
> Tim> I need to conditionally (based on a --with configure option)
> Tim> add a fairly large number (~50) of sources to foo_SOURCES.
>
> What version of automake are you using?
Some snapshot I took from the cvs automake a month or so ago. I'll
update my setup and see if it helps.
> [snip]
> T
Hi,
I need to conditionally (based on a --with configure option)
add a fairly large number (~50) of sources to foo_SOURCES.
First I tried
OPTIONAL=
if MYCONDITIONAL
OPTIONAL = lotsasource.c lotsayacc.y
endif
foo_SOURCES = $(REGULAR) $(OPTIONAL)
but that didn't work; automake complains that OP
> The rule is :
>
> modnam.def : ttimes.f
This means 'ttimes.f must be up-to-date in order for this rule,
which makes modnam.def up-to-date, to be able to run'. From what
you say, this is not what you mean.
> echo " data modnam/'$(datadir)'" > modnam.def
>
> and i need this file t
On 29 May 2001 23:29:57 -0400, Steven G. Johnson wrote:
>
> > You can even arrange to have the objects kept in subdirectories using:
> > AUTOMAKE_OPTIONS = subdir-objects
> > This option isn't really documented yet, but it is on my to-do list.
>
> I assume you mean that bar/baz.c is normally
> > If AM_MISSING_PROG actually checks
> > for the program in question before using 'missing --run $program', there
> > would be no such problem.
>
> The point is to avoid having to test for the program at configure
> time, since only developers are going to need it and, for them, the
> overhead o
> > I've noticed that if you try to build a texi file that has an error
> > you get a warning from the `missing' program:
>
> Presumably missing should check, when the execution of a program
> fails, whether the program can be found in the PATH or not, and only
> report its warning if it finds th
Hmm - I should have caught this sooner, but I only
update my automake tree sporadically.
The following problem exists: a new "Automake" directory
has been added to the tree at the top level. However,
on case-insensitive filesystems (such as DOS/Win32), this
clashes with the 'automake' script.
So
> You're right: line endings are to blame... the funny thing is that I got
> the sources from a Linux CVS server, and the uncorrect line endings seem
> to have been added during the dowloading... (actually I used WinCVS, so
> this is quite likely).
If you're using WinCVS and working with Unix/Lin
> I really think we can discover them all. The thing is that index can
> be created at will. So unless you actually look for used indexes, you
> can never be sure you don't forget something.
Wouldn't using the -c option to texi2dvi solve this? That way, the index
files don't need to be cleaned
> cmdline.c \
> main.cc errors.cc stringtable.cc tables.cc nodevis.cc \
>
> and the problem seems to be that \ in myprog_SOURCES is not recognized!
>
> Am I doing something wrong?
> Notice that this problem only takes place with cygwin
>
Might be an EOL issue;
> Thanks, but I was really asking the question for the whole *project*.
> With PRCS I can talk about revision n - 1 of the *project*, i.e., the
> full set of the files. According to private messages with Lars
> (Hecking :), you need to tag to be able to do that. So I dropped this
> idea and I'm
On 27 Mar 2001 09:57:08 +0200, Ralf Corsepius wrote:
> # ./configure
> checking for style of include used by make... include
>
> # make
> /bin/sh ./config.status --recheck
> running /bin/sh ./configure --no-create --no-recursion
> checking for style of include used by make... #
Is th
I'm sure other people on this list will tell how this can or cannot
be achieved in an autotools-specific way, but you could
get what you want the same way you get your 'generic' sources to
behave. In your 'foo.c' example, you could have a foo.c in your
'common' directory, which simply forwards to
> > +case "$foo_dir" in
> > + [\\/]* | ?:[\\/]) # Absolute
> ^ missing a `*' here, I suppose
Yep. Good catch.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Akim Demaille
Sent: Wednesday, February 21, 2001 10:43
To: Tim Van Holder
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Manual additions (DOS issues)
"Tim Van Holder" <[EMAIL PROTE
[Arg - damn outlook keeps sending mail before I want it to ]
> Plenty of thanks!
I'd like to say it was a pleasure, but writing docs never is :-)
> @bullets are atrocious! We use @minus.
Fine by me. Note that the only two other @itemizes in the manual
both use @bullet.
> I removed the @*, AFAI
ly thought there was some text about this issue in
> there. So yes, your proposal is gladly accepted :)
OK - here goes. I've listed '[\\/]* | ?:[\\/]*' as the canonical
absolute path test; I'll submit patches to use this throughout autoconf
later.
2001-02-20 Tim Van
> > - /* | [A-Za-z]:*) ;;
> > - */*) prog="`pwd`/$prog" ;;
> > + [/\\]* | [A-Za-z]:[/\\]*) ;;
> > + *[\\/]*) prog="`pwd`/$prog" ;;
>
> > @@ -11,7 +11,7 @@
> > # Always use an absolute srcdir. Otherwise symlinks made in subdirs
> > # of the test dir just won't work.
> > case "$srcdir" in
> > -
> I am wondering if the new preferred way of an empty AC_OUTPUT
> and use of AC_CONFIG_FILES in autoconf-2.49c is presently
> known to automake-1.4d or does automake still require the
> old way of doing AC_OUTPUT. Thanks.
CVS automake, and 1.4d too I believe, should support both the
old and the n
>> >* remake-hdr.am (@STAMP@): Use .T as suffix for the
>> >temporary file.
>>
>> You should probably patch autoconf's autoreconf too.
>
> > What part would need patching?
>
> The one that choose stamp file names like those created by automake.
Right - I hadn't noticed this:
stamp
ges my local autoreconf currently has are
listed below; I don't think they're critical, but they
might as well go in.
2001-02-11 Tim Van Holder <[EMAIL PROTECTED]>
* autoreconf.sh: Improve support for DOS paths.
Index: autoreconf.sh
=
> Nope, afraid not. Where did you get this mkinstalldirs?
> It isn't in the Cygnus tree. It also isn't in the gdb or gcc trees
Hmm - then I don't really know where I got it. Some GNU package,
I guess. Is may be an antiquated version; I didn't check the
older CVS revisions.
> (which some people
> Tim> 2001-02-10 Tim Van Holder <[EMAIL PROTECTED]>
> Tim> * m4/sanity.m4: Quote AC_MSG_RESULT's argument.
>
> Why?
As I understand it, the current convention is that ALL arguments
to autoconf macros should be quoted (even trivial ones like
'yes' and &
stamp-h1 and stamp-h1T resolve to the same file name on MSDOS,
so use stamp-h1.T instead.
Note that problems will still arise if stamp-h1 and stamp-h10
need to be present in the same directory.
2001-02-10 Tim Van Holder <[EMAIL PROTECTED]>
* remake-hdr.am (@STAMP@): Use .T as
big deal given the decidedly unstandardised
PC directory structure).
2001-02-10 Tim Van Holder <[EMAIL PROTECTED]>
* mkinstalldirs: Update with latest from Cygnus build
tree. Don't try making a dir when it already exists.
Index: mkinstalldirs
=
2001-02-10 Tim Van Holder <[EMAIL PROTECTED]>
* m4/sanity.m4: Quote AC_MSG_RESULT's argument.
Index: m4/sanity.m4
===
RCS file: /cvs/automake/m4/sanity.m4,v
retrieving revision 1.11
diff -u -r1.11 sanit
2001-02-10 Tim Van Holder <[EMAIL PROTECTED]>
* ylwrap: Support DOS-style absolute paths. Don't use
'ln -s' on DOSish systems.
* tests/defs: Support DOS-style absolute paths.
* tests/installsh.test: Support DOS-style absolute
> > How can I make a Makefile based on automake to be conditionnal
> > at make time and not at configure time.
> Basically, you can't. This just can't be done with portable Makefile
> rules, in general.
Maybe you can have something like:
foo:
@if test; then \
$(MAKE) foo-true;
>(_AM_DIRNAME): helper function which basically implements an sh
>`dirname` in m4
Only have 1 problem with it: no support for DOS-style paths (and this is
conveniently not tested in your dirname.test either :-P).
It's bad enough working on patches for proper DOS/Win support when pe
> Morten> Emacs Lisp comes to mind.. ;-)
>
> Not exactly: AFAIK, you can't freely hook whatever function: you hook
> on existing hooks. Right?
Yes the 'hook' concept in Emacs Lisp requires a function to explicitly
run those hooks, i.e. hooks are only available if the person writing
a routine ma
76 matches
Mail list logo
