On 22 November 2011 15:50, Bob Friesenhahn wrote:
>
> It would be useful to enumerate the user-visible benefits if Automake can
> depend on using GNU make. Otherwise it is difficult to do a cost/benefit
> analysis from the user perspective. Can you and others please brainstorm a
> list of benefi
On 22 November 2011 20:48, Bob Friesenhahn wrote:
>
> It would be quite useful for a FSF project to be spun-up to create an
> embeddable/small language interpreter and standard library which is capable
> of efficiently implementing complex make-like functionality ('automake') as
> well as providin
"Before we illustrate these two possibility"
possibility -> possibilities
On Mon, 8 Jan 2007, Ralf Wildenhues wrote:
That would be Automake's or make's responsibility.
I've already been told the opposite (owing to my ineptitude, this was
off-list as well); Mike Frysinger said:
"either way, it'd be a libtool issue ... libtool provides the
automake/autoconf code t
On Wed, 10 Jan 2007, Ralf Wildenhues wrote:
Could you please recheck whether this issue persists for you with
Automake 1.10,
No, it works fine, thanks. I hadn't realised that 1.10 had been released,
nor that my GNU/Linux distribution already contains it!
--
http://rrt.sc3d.org/ | think tank
On Wed, 10 Jan 2007, Ralf Wildenhues wrote:
Hmm, which documentation are you looking at? Let's see:
Automake 1.9.x never knew about datarootdir, and 1.10 doesn't have the
above wording at all. Some Autoconf versions may have had it, but the
current (2.61) one is different. I guess you're look
automake 1.10 has started complaining about GNU Make-isms. This is fair
enough, but it seems to satisfy a fairly small constituency (those using GNU
autotools without GNU make) while annoying a rather larger one (those who
enjoy the power of GNU make). While I understand why you'd want to make
Node: CVS
" This timestamp shift is troublesome when both sources and generated
files are kept under CVS. Because CVS processes files in alphabetical
order, `configure.ac' will appear older than `configure' after a `cvs
update' that updates both files, even if `configure' was newer than
`configu
I imagine this question has been asked before, but searching the
archives, the net and the manual didn't help me with the following:
I have a C program which loads some scripts at runtime. These are
stored in datadir (e.g. /usr/local/share/prog). But I also want to be
able to run the program from
On 14 March 2010 22:39, Martin Kalbfuß wrote:
> Am Sonntag, den 14.03.2010, 22:29 + schrieb Reuben Thomas:
>> I imagine this question has been asked before, but searching the
>> archives, the net and the manual didn't help me with the following:
>>
>> I h
On 15 March 2010 01:30, Bob Friesenhahn wrote:
> On Sun, 14 Mar 2010, Reuben Thomas wrote:
>
>> I imagine this question has been asked before, but searching the
>> archives, the net and the manual didn't help me with the following:
>>
>> I have a C program
On 21 March 2010 11:40, Ralf Wildenhues wrote:
> * Russell Shaw wrote on Sun, Mar 21, 2010 at 11:18:03AM CET:
>> But it is somewhat big, and i had already searched through the online
>> one a lot first. It is no wonder it takes noobs so long to get productive.
>
> I'm not sure how to help that. I
2010/3/22 Russell Shaw :
> Steffen Dettmer wrote:
>>
>> * On Sun, Mar 21, 2010 at 10:27 AM, Ralf Wildenhues wrote:
>>> BTW, execution of built programs like this makes your package unsuitable
>>> for cross-compilation. Just so you're aware of that.
Not true. automake does not have explicit suppor
2010/3/22 Alfred M. Szmidt :
> If searching is the problem
*Web* searching is the answer, not the problem.
> how does the indices not fix the problem?
I rarely find anything useful in the indices other than particular
functions or variables. Rarely, in GNU manuals, concepts, but that is
because
On 23 March 2010 06:03, Ralf Wildenhues wrote:
> Hello Reuben,
>
> * Reuben Thomas wrote on Mon, Mar 22, 2010 at 04:44:17PM CET:
>> 2010/3/22 Russell Shaw:
>> > Steffen Dettmer wrote:
>> >> * On Sun, Mar 21, 2010 at 10:27 AM, Ralf Wildenhues wrote:
>>
On 23 March 2010 10:15, Steffen Dettmer wrote:
>> This illustrates a weirdness of autotools: poor support for
>> installing interpreted languages, and also conversely for
>> build-time compiled programs.
>
> Yes, also for coffee-cooking there is poor support only. :-)
Sure, but autotools is for b
On 23 March 2010 17:15, Alfred M. Szmidt wrote:
>
> 2010/3/22 Alfred M. Szmidt :
> > If searching is the problem
>
> *Web* searching is the answer, not the problem.
>
> It isn't when you are not connected to a network.
I usually wait until I am; it often takes me rather longer to answer
que
On 23 March 2010 18:12, Alfred M. Szmidt wrote:
> You say that the manuals are poor
I said that the indices are poor, specifically at indexing concepts
rather than just keywords, function names &c., in general. I also said
that the manuals in general are excellent.
> and that it is obvious, but
On 11 April 2010 23:37, Bob Friesenhahn wrote:
> Yes, compression is useful. However, the cost of pushing the algorithm
> close to the limit does incur costs as well. For many packages, getting 99%
> of the max in 1/2 the time is a worthy tradeoff. This is similar to the
> decision to use -O2 as
"Script are not distributed by default" -> "Scripts are not
distributed by default"
--
http://rrt.sc3d.org
This is actually a bug that affects several autotools packages,
excluding autoconf, for which it's already fixed: the invocation node
is added to the info dir as "automake" which means that
info automake
goes to the invocation node, not the Top node.
autoconf calls its invocation node autoconf-i
21 matches
Mail list logo
