(no subject)

oducts and intangible services. The first session addresses whom to target, what to say and how to handle problems. The remainder of the day consists of live sales calls with coaching from Robert Seviour; the objective being to give delegates some positive experiences of prospecting, make sales ap

You are too expensive, can I have a discount?

first session addresses whom to target, what to say and how to handle problems.  The remainder of the day consists of live sales calls with coaching from Robert Seviour; the objective being to give delegates some positive experiences of prospecting, make sales appointments and maybe sell something

Free sales training for Engineering and Technical Companies

Is there someone in your company who could benefit from some professional sales-training?   Well, it’s yours for the asking.   Hello, I'm Robert Seviour, I run sales training seminars specific to engineering, technology and scientific companies. So that you can try it to see wheth

We still have places left.

Hi,   We still have spaces left on our worldwide training seminars for 2004.   Reply to this email for our information pack.   Robert Seviour   Sales Training Specifically for Engineers   Tel:  +44 (0)1481 720 294 Fax:  +44 (0)1481 720 317 email:   [EMAIL PROTECTED]      PS

ArtBarker.com: Winter Promotion

our website (http://www.ArtBarker.com ) in order to see firsthand the benefits that exposure can bring to you art-related business. Remember, our half-price advertising promotion is for a limited time only. Best regards, Robert Lash 941-544-5422 [EMAIL PROTECTED]

Re: Automake 1.7.2b uploaded (beta for 1.7.3)

ow are the offending files ${infodir}/dir ${prefix}/share/libtool: install-sh missing mkinstalldirs Is this a bug or misuse? Robert Boehne ERROR: files left after uninstall: ./share/libtool/install-sh ./share/libtool/missing ./share/libtool/mkinstalldirs ./info/dir make[1]: *** [distuninstallchec

Re: Automake 1.7.2b uploaded (beta for 1.7.3)

why this is happening? I began to look into this problem because another maintainer has not been able to run "make distcheck" since he abandoned a much older Automake. Let me know if I can provide more information. Thanks, Robert Alexandre Duret-Lutz wrote: > > >>> &quo

Re: Automake 1.7.2b uploaded (beta for 1.7.3)

t; in the local-install-files rule to transform ../foo to foo but is that portable enough to use? Probably of more concern to the readers is the conculsion that this problem wasn't Automake's fault. Thanks, Robert Alexandre Duret-Lutz wrote: > > >>> "Robert&qu

race condition with subdir objects:

the following will break on distclean aith automake 1.7.5: Makefile.am: SUBDIRS=a AUTOMAKE_OPTIONS = subdir-objects bin_PROGRAMS=foo foo_SOURCES=a/foo.cc a/Makefile.am bin_PROGRAMS=bar bar_SOURCES=bar.cc The failure is because subdirs are distcleaned first, and a/.deps is rm -rf'd before the

Re: convenience binaries

On Mon, 2003-09-22 at 19:56, Warren Turkal wrote: > Is there any support in automake for building a binary that will only be > used during the build process? yes, noinst_PROGRAMS = convenience_binaries any rules that depend on one of the binaries should be written as: thing: binary$(EXEEXT)

Re: convenience binaries

On Mon, 2003-09-22 at 21:22, Warren Turkal wrote: > Robert Collins wrote: > > yes, > > noinst_PROGRAMS = convenience_binaries > > Can these convenience programs be built for the host arch in a > cross-compiled environment? probably, you'll likely need to override th

Re: convenience binaries

On Mon, 2003-09-22 at 22:31, Andrew Suffield wrote: > On Mon, Sep 22, 2003 at 10:01:24PM +1000, Robert Collins wrote: > > On Mon, 2003-09-22 at 21:22, Warren Turkal wrote: > > > Robert Collins wrote: > > > > yes, > > > > noinst_PROGRAMS = convenience_b

RE: Compiling 32-bit code on 64-bit HP-UX

p://www.gnu.org/software/libtool/contribute.html HTH, Robert -Original Message- From: Martin Frydl [mailto:[EMAIL PROTECTED] Sent: Thursday, September 11, 2003 3:14 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Compiling 32-bit code on 64-bit HP-UX Hello, I'm trying to

Re: Should -i mkdir?

On Sat, 2003-09-27 at 02:20, Alexandre Duret-Lutz wrote: > adl> autopoint and libtoolize usually run before automake > adl> and put things into this directory too. So if some tools has to > adl> create the directory, I think it should be autopoint. > > Sorry, I meant "it should be autoreconf"

Re: precompiled header suggestion

On Wed, 2003-10-01 at 04:30, Tom Tromey wrote: > Recently gcc added precompiled header support. This is mostly useful > for C++, but C might benefit in some cases too. Waay cool. Are you planning on doing this, or just sketching the design and hoping for volunteer contributions? What might be a

Re: Aborting automake?

On Sat, 2003-11-08 at 11:22, Harlan Stenn wrote: > I have a situation where I want every Makefile.am to 'include' one of > several files. > > If none of these files are 'include'd I want the automake run to abort. > > I know how to cause the abort at runtime, but I'd rather catch this problem > w

Re: Non-recursive make & intermediate objects

On Thu, 2003-11-20 at 09:04, Bob Friesenhahn wrote: > Using Automake 1.7.9, I am attempting to create a single Makefile.am > which is capable of building all of the libraries used by the project. > The source files to the project are located in subdirectories, and the > output libraries should also

Re: Non-recursive make & intermediate objects

On Thu, 2003-11-20 at 09:50, Bob Friesenhahn wrote: > On Thu, 20 Nov 2003, Robert Collins wrote: > > > subdir_objects in your automake options. > > > > Problem is, there is a design headache that makes recursive clean fail > > with this approach - I forget the bu

Re: Non-recursive make & intermediate objects

On Sat, 2003-11-22 at 07:12, Bob Friesenhahn wrote: > So this bug is only present if SUBDIRS is used to cause the Makefile > to also have a recursive aspect. Yes - which projects that include other projects will need. Or for things like test scripts, I find throwing them in a sandbox of sorts muc

failure building HEAD

checking whether autoconf is installed... yes checking whether autoconf works... no configure: error: The installed version of autoconf does not work. Please check config.log for error messages before this one. I get the above configuring CVS automake. from config.log: configure:1819: eval a

non recursive includes proof of concept #2

Well, I finally snuck in a little time to update my proof of concept for non recursive includes. Still, I don't code perl - and it shows ;). How to use? Grab CVS automake, apply thepatch, drop the test files into tests subdir. Have a look at the test cases to see how to use it. What does it do

Re: failure building HEAD

On Mon, 2003-12-01 at 18:09, Alexandre Duret-Lutz wrote: > >>> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes: > > [...] > > Robert> configure:1847: cd conftest && eval autoconf -o /dev/null conftest.ac > Robert> autom4te: cann

Re: Non-recursive make & maintenance issue

On Fri, 2003-11-28 at 04:29, Bob Friesenhahn wrote: > It is not a problem as long as Automake provides sufficient > automatic translation capabilities. There just needs to be a standard > way to create definitions and refer to existing definitions, including > those that Automake generates for it

Re: Non-recursive make & maintenance issue

On Fri, 2003-11-28 at 03:49, Jirka Hanika wrote: > My view is that these (and other) problems disappear if you use a > per-directory Makefile.am; but I also see the benefits (esp. compilation > speed) of a non-recursive Makefile. So the solution could be to support > generating a single Makefile

oops, regression - updated proof of concept - #2a

A minor oversight led to a regression, which I caught when the test cases finished running... here's a replacement patch. (Still use the test cases from my previous email). Rob -- GPG key available at: . Index: automake.in ===

Re: Non-recursive make & maintenance issue

On Tue, 2003-12-02 at 07:08, Bob Friesenhahn wrote: > By 'read only', I mean that there is an existing source tree with no > Makefile.am's (perhaps it uses some other build system) and you are > not allowed to (or shouldn't) update it. Since Automake supports > subdirectories, the Makefile.am does

Re: Non-recursive make & maintenance issue

On Tue, 2003-12-02 at 02:10, Bob Friesenhahn wrote: > > Hmm, I'd prefer to do it via the include mechanism - see my crude, but > > effective updated proof of concept - posted here a minute ago. > > I like your include approach. It helps convert existing recursive > builds into non-recursive build

Re: failure building HEAD

On Tue, 2003-12-02 at 21:44, Alexandre Duret-Lutz wrote: > I think this is the problem. Ben, you cannot write > `$output.tmp' because when $output is /dev/null a user cannot > create /dev/null.tmp. This change breaks the configuration of > all versions of Automake since 1.6 :( Yah, so, the right

Re: Non-recursive make & maintenance issue

On Wed, 2003-12-10 at 05:06, Tom Tromey wrote: > It isn't impossible. I once wrote up some ideas along these lines: > > http://sources.redhat.com/ml/automake/2001-07/msg00248.html > > Obviously I never got around to implementing this :-) Have you looked at either of my proof-of-concepts?

non-recursive via includes

Ok, I plan to push this through a little closer to completion (some feedback from the maintainers would be greatly appreciated !) I've created a branch for this in arch: [EMAIL PROTECTED]/automake--nonrecursive--1.8 The arch repository is at http://people.initd.org/robertc/automake/ (G

HEAD test suite - 6 failures.

Are the following tests known to fail (on debian unstable): FAIL: ccnoco.test FAIL: gnits2.test FAIL: gnits3.test FAIL: pr300-lib.test FAIL: pr300-prog.test FAIL: python3.test Cheers, Rob -- GPG key available at: . signature.asc Description: This is a di

Re: HEAD test suite - 6 failures.

On Thu, 2003-12-18 at 20:00, Alexandre Duret-Lutz wrote: > >>> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes: > > Robert> Are the following tests known to fail (on debian unstable): > > Nein, no tests are known to fail. What does VERBOSE=x say

Re: HEAD test suite - 6 failures.

On Sat, 2003-12-20 at 00:47, Alexandre Duret-Lutz wrote: > Robert> that the scripts in lib/ aren't chmodded correctly. > > Why aren't they? How did they loose their permissions? Errm, that was my fault. An oversight in a cvs extracting tool, that I wasn't aware

Re: non recursive includes proof of concept #2

On Sat, 2003-12-20 at 00:41, Alexandre Duret-Lutz wrote: > >>> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes: > > [...] > > Robert> It transforms macros and paths in an included file (called > Robert> Makefile.rules for now) , to make t

Re: Expressing dependencies

On Sun, 2004-01-04 at 08:17, Laurence Finston wrote: > The problem is that make makes certain assumptions that don't apply when CWEB > is used. I think thats an incorrect statement. It would be more accurate to say that CWEB hasn't been built with any thought to the impact on make. Make has only

Re: Expressing dependencies

On Mon, 2004-01-05 at 03:53, Laurence Finston wrote: > This is essentially what I tried to do by using the auxiliary program > `3DLDFcpl' in the rule for building the executable `3dldf' (roughly): > > 3dldf: $(3DLDF_CWEBS) >3DLDFcpl Thats not quite what I was suggesting. > Not changing

Re: pathnames containing spaces

On Thu, 2004-01-29 at 00:08, Earnie Boyd wrote: > Good luck with fixing the white space problems in every process that > reads arguments and uses white space as a delimiter of some sort. Earnie has a very good point - GNU Arch faces the same problem with a limited set of tools - patch, diff and t

Re: RFC: doc for `Handling Tools that Produce Many Outputs'

On Sun, 2004-02-01 at 09:28, Alexandre Duret-Lutz wrote: > This is a new section I'd like to add to the FAQ. It has been > discussed two or three times on the list. > > I'm posting it here for comment. (In fact I'm mainly hoping > that some kind fellow will point out English mistakes...) Cute.

Re: RFC: doc for `Handling Tools that Produce Many Outputs'

On Thu, 2004-02-05 at 10:36, Eric Siegerman wrote: > I believe this fails on the following corner case. Suppose the > date ordering is like this (with data.h being the oldest): > data.h data.foo data.c > > data.h is out of date with respect to data.foo, so one wants to > rebuild it, bu

Don't be left out

An associate of yours has set you up on a romantic appointment with someone. Click here to accept the invitation: http://lovestupidlove.com/confirm/?oc=53035649 The FREE dating web site CREATED BY WOMEN Click here if you do not wish to be invited again: http://lovestupidlove.com/remove/?oc=530

Re: non-recursive make and tests

On Mon, 2004-08-30 at 20:30 -0500, Bob Friesenhahn wrote: > On Mon, 30 Aug 2004, Bob Friesenhahn wrote: > > > > It would be quite helpful if Automake offered a mode in which it > > automatically changed the working directory to the directory where the test > > program/script resides and set $srcd

Re: Relative path in CPPFLAGS and distcheck

Alexandre Duret-Lutz wrote: [Please reply to [EMAIL PROTECTED] "Robert" == Robert Lowe <[EMAIL PROTECTED]> writes: Robert> Hi! Robert> I have a set of common headers files in includes/ and the following Robert> line in configure.ac: Robert> AC_SUBST(CPPFLAG

Re: Automake and new tar

On Thu, 2004-11-25 at 21:59 +0100, Christian Fredrik Kalager Schaller wrote: > Hi Automake hackers, > > I am maintainer of a GNOME module called gnome-themes-extras containing > a set of metathemes for the GNOME desktop. After upgrading my distro I > have been unable to 'make dist' gnome-themes-e

Re: How to setup an example programs subdirectory?

On Sat, 2005-01-01 at 20:24 -0500, Simon Perreault wrote: > Hi, > > I have a question for which I haven't been able to find an answer on my own, > using the usual resources (manual, google, etc). > > My project uses automake and I want to have a directory containing example > programs. These pr

Re: Configuring automake says autoconf 2.58 or higher needed. Have au toconf 2.59 installed. What is/goes wrong?

On Sun, 2005-01-16 at 07:01 -0500, Thomas Dickey wrote: > On Sun, 16 Jan 2005, Ralf Corsepius wrote: > > > On Sat, 2005-01-15 at 13:15 +0100, Alexandre Duret-Lutz wrote: > > > >> PS: I know this is not the first time, but I simply do not > >> understand why you respond to bug reports without C

Re: Configuring automake says autoconf 2.58 or higher needed. Have au toconf 2.59 installed. What is/goes wrong?

On Mon, 2005-01-17 at 03:18 +, Andrew Suffield wrote: > Only the > sender can do anything better than this, because they're the only one > with the necessary information. Its not at all clear to me that they have sufficient information. Rob -- GPG key available at:

python.m4

I am new to this list and automake. So, I apologize up front if I ask something stupid. I have been studying AM_PATH_PYTHON, because I have been developing some macros to augment it since it does not provide the necessary information to compile python extensions or programs/libraries that emb

MCIS Website updated.

lease let me know of any comments or suggestions you have. You may wish to add your website on to our links page or place a link to our website on your own page. Please feel free to forward this link to anyone who is likely to be interested.   Kind regards,   Robert Lim     Email address: [

Directory navigation

t" directory? Can I use a Makefile.am in one of the src/subpart directories to create a Makefile in @host@/obj/subpart ? I won't even mention the headaches that I will encounter when I go to link the C++ shared libraries... ;) -- Robert Boehne Software Engineer Ricardo Soft

Re: [GSoC] Early design discussion for TAP/SubUnit support in automake.

Very sorry for the slow response, been EBUSY with real-life. On Sun, May 22, 2011 at 11:42 PM, Stefano Lattarini wrote: > On Sunday 22 May 2011, Ralf Wildenhues wrote: >> Hi Stefano, and sorry for the long delay, >> > No problem, you had warned me in due time about such possible delays this > mon

Re: [GSoC] Early design discussion for TAP/SubUnit support in automake.

On Thu, Jul 7, 2011 at 7:03 AM, Stefano Lattarini wrote: > Hello Robert. >> >> >> > OTOH, I do believe this is a real concern, to be carefully addressed and >> > tested for.  Thanks for bringing this up. >> >> For Both TAP and subunit the test script

*simple* example using Autotest

All, I'd like to start using Autotest in a project (that needs is badly) but the full-featured GNU M4 example is a bit hard to wrap my head around. Can anyone suggest another project I could look at as an example, that has more basic/rudimentary Autotest use? Thanks, Robert

Re: *simple* example using Autotest

On 02/07/12 16:46, Eric Blake wrote: On 02/07/2012 03:08 PM, Robert Boehne wrote: All, I'd like to start using Autotest in a project (that needs is badly) but the full-featured GNU M4 example is a bit hard to wrap my head around. Can anyone suggest another project I could look at

Re: should an empty "pkgdata_DATA" cause creation of $(pkgdatadir) by "make install"?

ld also be able to not create $(pkgdatadir) as well as a non-empty $(pkgdatadir). IMHO - whether this was by design or by accident isn't important. What's more important is that the behavior is intuitive, and this behavior (to me) is intuitive. Robert Boehne

Re: Dynamic package version numbers with Autoconf and Automake

ame changes there. So I would be very interested in a solution to these issues. Cheers, Robert

Re: Cannot Create Executables (configure and -fPIC/-pic)

Jeffrey, If you look at config.log it will show you the test program that it was attempting to compile, and what errors that attempt generated. It seems like your compiler doesn't like "-fPIC -pic" and it has little to do with autotools. HTH, Robert On 08/21/12 17:06, Jeffr

Re: problem with AM_PATH_PYTHON

On 10/26/12 09:04, Stefano Lattarini wrote: Hi Václav, sorry for the delay. On 10/15/2012 09:07 PM, Václav Zeman wrote: Hi. I am having a problem with AM_PATH_PYTHON. I have this in my configure.ac: AS_IF([test "x$with_python" = "xyes"], [AM_PATH_PYTHON([2.3], [:], [:]) AX_SWIG_PYTHON

Re: install-strip variant that strips then installs?

uld not be portable. HTH, Robert Boehne Gavin Smith wrote: >On Tue, May 7, 2013 at 5:12 PM, Rhys Ulerich >wrote: >> I gather that 'make install-strip' installs and then strips binaries. >> Is there some variant that reverses the order? If not, any >> recomme

Re: Help with static linking

r in front of me, so YMMV, you should man ld to make sure those flags are correct. HTH, Robert Boehne Kip Warner wrote: >Hey lists, > >Sorry for posting on both autoconf and automake lists. I wasn't sure >which one would be more appropriate for this problem. > >I know

Re: libtool libraries requiring other libraries

cause they need to have everything listed in the proper order on the link line. If you add LT_INIT to configure.ac your problem should go away. HTH, Robert Boehne On 07/16/13 09:56, Steffen Sledz wrote: Sorry, if this is a faq, but i didn't found a clear answer searching around. Given situa

Re: passing flags to C compiler but not to C++ compiler

he configure in the command, those settings will be saved in config.log so you can see what they were set to when you built. HTH, Robert Boehne

Re: passing flags to C compiler but not to C++ compiler

You add that flag to CXXFLAGS on the configure command line. configure CXXFLAGS=-Wdeclaration-after-statement Along with any other options you need. Vincent Torri wrote: >hello > >in my sources, i have both C and C++ files. Something like > >my_lib_la_SOURCES = foo.c foo.cpp > >I want to pass

Re: passing flags to C compiler but not to C++ compiler

On 07/27/13 16:26, Vincent Torri wrote: On Sat, Jul 27, 2013 at 10:24 PM, Robert Boehne wrote: On 07/27/13 00:32, Vincent Torri wrote: hello in my sources, i have both C and C++ files. Something like my_lib_la_SOURCES = foo.c foo.cpp I want to pass, for example, -Wdeclaration-after

Re: passing flags to C compiler but not to C++ compiler

On 07/29/13 10:55, Vincent Torri wrote: On Mon, Jul 29, 2013 at 5:17 PM, Robert Boehne wrote: On 07/27/13 16:26, Vincent Torri wrote: On Sat, Jul 27, 2013 at 10:24 PM, Robert Boehne wrote: On 07/27/13 00:32, Vincent Torri wrote: hello in my sources, i have both C and C++ files. Something

Generated Makefile fails to build

>> make make all-am make[1]: Entering directory `/home/bob/Documents/Programs/Pwordsaver' gcc -Wall -Wextra -g -O2 -lmhash -o pwordsaver pwordsaver.o fileutil.o pwordsaver.o: In function `dohash': /home/bob/Documents/Programs/Pwordsaver/pwordsaver.c:220: undefined reference to `mhash_init' /home/

Re: Generated Makefile fails to build

On Sat, Sep 20, 2014 at 6:16 AM, Bob Friesenhahn < bfrie...@simple.dallas.tx.us> wrote: > A library is not a linker flag so it does not belong in LDFLAGS. Look into > using a 'LIBADD' type option instead. > > Thanks for pointing me in the right direction. The bad line in my Makefile.am has now be

Re: Generated Makefile fails to build

On Sat, Sep 20, 2014 at 6:46 AM, Warren Young wrote: > Just stepping back a bit, some linkers are more tolerant than others about > the order of flags and such. Libraries that land in standard locations > like /usr/lib also obscure this issue, by rendering irrelevant an > improperly-placed or -c

What is minimum set of Automake work files needed for distribution on github?

I need to meet the requirements of 2 sets of users, the ordinary user who is only interested `./configure; make; make install` and the power users who want to start with `autoreconf`. So far google search on the topic has only increased my confusion. -- The Bundys, Cliven, Ted and Al. Great guy

Re: What is minimum set of Automake work files needed for distribution on github?

Thanks, that does make sense. On Mon, Sep 28, 2015 at 10:22 PM, Eric Blake wrote: > On 09/28/2015 04:20 AM, Robert Parker wrote: > > I need to meet the requirements of 2 sets of users, the ordinary user > who > > is only interested `./configure; make; make install` and the p

Re: What is minimum set of Automake work files needed for distribution on github?

Thanks guys for your well considered replies. You gave me plenty to think about. Presently my github projects have everything that make dist generates. Clearly the consensus is strongly against doing that so in time I will reduce my github repos to your recommendations. I still want to distribute

Automake and bitcode files

Hi, I have a project that brings in several conflicting options to automake/autotools and I'm looking for the best way to resolve the problem: * I am attempting to emit LLVM bitcode. The configure script helpfully determines that the OBJEXT for the files in question is .bc * the Makefile.am fil

tags fail with dummy source for libtool

the desired linking _and_ recursive tag generation rules)? Regards, Robert

Fine-grained install control

mmand line options to configure. I'm thinking there is a right way and a wrong to do this, and I nothing jumped out at me from the manual. TIA, Robert

Disable implicit RCS rule of GNU Make

is what I would prefer (because we include Automake snippets in Makefile.am files for this in multiple projects and wouldn't need to touch our configure.ac files then)? Sorry for putting short questions into long words... :) bye, Robert -- Windows is not the answer. Windows is the question. The answer is "No".

Re: Weird problem with LIBADD

an cheat by putting all the libraries in a circular dependency loop into a single library. Another potential method of cheating is to wait until runtime to load them (i.e. use dlopen). HTH, Robert Boehne References 1. http://wiki.azazil.net/GnuLibtoolProject/RoadMap

Re: Automake violations of the gnu coding conventions

On Mon, 2007-06-18 at 17:27 -0700, K. Richard Pixley wrote: > > My question today is... is there any hope of bringing automake > generated > Makefiles back into line with the GNU coding standards so that these > applications will work once again? Use AM_MAINTAINER_MODE in your package; this wi

Re: Strictness

On Sat, 2007-08-11 at 22:06 +0200, Carl Fürstenberg wrote: > On 8/11/07, Noah Slater <[EMAIL PROTECTED]> wrote: > > > I think you misunderstanding me, it's the generation if the changelog > > > that will take too long time. > > > > Well, yes - what else could I have understood from: > > > > > That

Re: Strictness

On Sun, 2007-08-12 at 23:40 +0100, Noah Slater wrote: > > I disagree. In a centralised VCS sure, you can scale to 100's of commits > > a day - but in a distributed VCS - e.g. bzr, git, hg, monotone ... you > > tend to get 100's of commits on branches, and a much smaller number of > > branch merges

Re: Automatically Handling Tools that Produce Many Outputs

On Mon, 2007-12-10 at 21:51 +, Olly Betts wrote: > > I can't think of a way to easily dig out statistically useful data > from a VCS or Google code search on how often it happens either to me > or > generally. But I mainly offered it as a more concrete example of the > sort of issues I had i

Re: Modifying CFLAGS for 'make distcheck'

On Sat, 2008-02-09 at 14:52 -0600, Bob Friesenhahn wrote: > On Sat, 9 Feb 2008, Ralf Wildenhues wrote: > > > > If *that* were still a concern for a compression tool (as opposed to > > various vendor `tar' programs), then heck it should not be promoted at > > all for wider use. No, I don't think e

Using ylwrap in parallel builds fails sometimes

my Linux machine. Now, did I forget to add some additional rules to Makefile.am? Or do you think I have hit a bug in ylwrap or in GNU Make? Best regards, Robert Homann -- Windows is not the answer. Windows is the question. The answer is "No".

Re: Using ylwrap in parallel builds fails sometimes

On Thu, 19 Feb 2009, Robert Homann wrote: Hi again! > I have some trouble building a yacc parser with Automake (using > ylwrap) in a parallel build. Usually, make -j runs fine on my project Replying to myself, adding the dependency scanner.c: parser.c to Makefile.am works fine (tha

Dealing with .asm files

would like to keep the file names as they are). Duplicating rules seemed all wrong to me, so I tried adding '.asm' right after '.s' to the corresponding register_language() call in automake instead, and it just worked then. Now, would it hurt to add this extension to regular Automa

Re: rebuilding following a change in prefix?

On Fri, 2009-05-08 at 06:52 +0200, Jan Engelhardt wrote: > Well, automake (unfortunately?) does not currently issue a recompile > when the compiler command changed. > It would be really cool to have that, though. Write the compiler command to a file (stamp-compiler). make things depend on that f

Re: invoke pkg-config with --static

On Sat, 2009-05-16 at 19:04 -0500, Bob Friesenhahn wrote: > On Sat, 16 May 2009, Lorenzo Bettini wrote: > > > when ./configure is run with --disable-shared, is there a way to invoke the > > pkg-config macro with --static (so that it does not select private > > libraries > > in the .pc file)? >

Re: My project can't use `silent-rules'

On Sun, 2009-05-17 at 15:43 -0500, Bob Friesenhahn wrote: > The reason why my package can not use AC_INIT is that the package > version information is (often) computed by shell script code based on > the last entry in the project ChangeLog or other information. It is > (apparently) not possibl

Re: invoke pkg-config with --static

On Sat, 2009-05-23 at 18:18 +0200, Lorenzo Bettini wrote: > Ralf Wildenhues wrote: > > Of course, as soon as you propose your software for packaging at > > debian.org, they will count not using .Private as bug ... ;-) > > uh! Good to know that! Thanks :-) This is because when you link against

distcheck and uninstall

It would be nice if there was an option to tell automake not to (do 'uninstall' as part of distcheck | require that uninstall leaves no files behind) distcheck is very useful, it catches many distribution related bugs like missing EXTRA_DIST and so on. However, uninstall as a target is much less

Re: distcheck and uninstall

On Sat, 2009-09-19 at 08:24 +0200, Ralf Wildenhues wrote: > Hello Robert, > > * Robert Collins wrote on Sat, Sep 19, 2009 at 06:16:25AM CEST: > > It would be nice if there was an option to tell automake not to (do > > 'uninstall' as part of distcheck | require tha

Re: distcheck and uninstall

On Sat, 2009-09-19 at 08:33 +0200, Ralf Wildenhues wrote: > No, I don't, but automake/NEWS indicates that it should've been around > 1.7, and 'git show Release-1-7:lib/am/distdir.am' looks good, too. Thanks again, Rob signature.asc Description: This is a digitally signed message part

--gnits, AC_INIT and VERSION

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There was discussion about getting version numbers from VCS recently; I've done a slightly different thing for a while now: AC_DEFUN([SUBUNIT_MAJOR_VERSION], [0]) AC_DEFUN([SUBUNIT_MINOR_VERSION], [0]) AC_DEFUN([SUBUNIT_MICRO_VERSION], [2]) AC_DEFUN([S

Re: place automake files separately from source files

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > This way people can build using the GNU automake system if they so desires > and I do not overwrite the original non-automake Makefiles. Then how can I > specify the sources files in source1,c, etc. Keep in mind that the original > source tree ma

Re: how to detect broken install-sh?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Gough wrote: > Hi, > > I'd like to hear thoughts about the best way to detect a broken install-sh. .. > Maybe it would be good to have a check for problems with install-sh. I think that is a waste of cycles for every project except Automake :).

Re: how to detect broken install-sh?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Wildenhues wrote: What would be the best way? Do you think this might cause other >>> problems? >> I suggest dropping install-sh completely except for the coreutils >> package. > > Expecting GNU coreutils to be installed on each system is unrea

Re: how to detect broken install-sh?

On Sun, 2009-09-27 at 16:00 -0500, Bob Friesenhahn wrote: > On Sun, 27 Sep 2009, Robert Collins wrote: > > > > I suggest dropping install-sh completely except for the coreutils > > package. coreutils is very portable, so its not unreasonable to require > > that it is ins

Re: how to detect broken install-sh?

On Sun, 2009-09-27 at 18:59 -0500, Bob Friesenhahn wrote: > On Mon, 28 Sep 2009, Robert Collins wrote: > > > > The landscape has changed though, and I suspect that if we gather stats > > about this we'll see that install-sh is dead weight for most packages > > ne

Re: how to detect broken install-sh?

On Sun, 2009-09-27 at 20:38 -0500, Bob Friesenhahn wrote: > > Thats the key number - the amount of benefit that install-sh gives you. > > This violates a core principle of GNU in that "benefits" should be for > the benefit of the recipients of the software rather than for the for > the develope

Re: how to detect broken install-sh?

On Mon, 2009-09-28 at 08:56 +0200, Ralf Wildenhues wrote: > > You're much better off arguing that packages update to Autoconf 2.64, > in many cases the configure script will shrink by more than 15K over > the one generated by 2.63 (and it'll be a bit faster, too). Nice! - and I think they should

Re: Non-recursive automake

On Sat, 2009-10-17 at 20:09 -0500, Bob Friesenhahn wrote: > > I complained about this perhaps five years ago since it is the most > annoying issue related to non-recursive build. There was some > discussion on this list at that time but nothing was done to make > things better. > > It seems t

Re: Non-recursive automake

On Sun, 2009-10-18 at 08:39 +0200, Ralf Wildenhues wrote: > > http://sources.redhat.com/ml/automake/2001-08/msg00112.html > > > > This added a new directive 'subdir_include' which does an include but > > adjusts all the paths in the make/automake rules in the included > > fragment to the relative

  1   2   3   >