On 13/05/13 02:28, Stefano Lattarini wrote:
> On 05/12/2013 06:29 AM, Michael Zucchi wrote:
>> Using $? will not suffice as a dependency check, as it's trivially easy
>> to create an example which will compile ok after a change but create a
>> broken jar. e.g. add a new abstract method to an abstr
the AM_CONDITIONAL documentation states it must always be executed. that's
fine. but what if i want to be lazy?
for example, i have code like so:
AC_DEFUN([_FOKER_DEFINE], [dnl
AC_DEFINE([FOKER_]$1[_]m4_toupper($3), [1], [Define is the ]$2[ is ]$3)
])
AC_DEFUN([_FOKER_ARCH], [_FOKER_DEFINE(
On 05/08/2013 02:12 AM, 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
recommendations for how to write one in an Automake-compliant manner?
Hi Rhys,
I'm tempted to believe the DESTDIR featu
Stefano Lattarini writes:
> On 05/12/2013 06:29 AM, Michael Zucchi wrote:
>> Hi again,
>>
>> I (mostly) just have an observation to add to the bug tracker discussion
>> on the dependency generation.
>>
>> Using $? will not suffice as a dependency check, as it's trivially easy
>> to create an ex
On 05/12/2013 06:29 AM, Michael Zucchi wrote:
> Hi again,
>
> I (mostly) just have an observation to add to the bug tracker discussion
> on the dependency generation.
>
> Using $? will not suffice as a dependency check, as it's trivially easy
> to create an example which will compile ok after a c
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
> recommendations for how to write one in an Automake-compliant manner?
>
> My unstripped binaries are absurdly
