On 02/23/2013 06:47 PM, Stefano Lattarini wrote:
On 02/14/2013 11:26 AM, Stefano Lattarini wrote:
OK, done. If there are no further objections, I will soon proceed to
re-write the experimental/preproc branch once again with the latest
version of these patches;
This has been done already.
On 02/14/2013 11:26 AM, Stefano Lattarini wrote:
OK, done. If there are no further objections, I will soon proceed to
re-write the experimental/preproc branch once again with the latest
version of these patches;
This has been done already.
then we can think when and how to merge it
into
On 02/08/2013 01:31 PM, Stefano Lattarini wrote:
On 02/08/2013 10:11 AM, Peter Rosin wrote:
On 2013-02-08 09:45, Peter Rosin wrote:
Stefano Lattarini wrote:
Fine as well. And of curse, if you want to speed thing up and have more
control on the final result, feel free to shepherd the pending
On 02/08/2013 01:31 PM, Stefano Lattarini wrote:
On 02/08/2013 10:11 AM, Peter Rosin wrote:
On 2013-02-08 09:45, Peter Rosin wrote:
Stefano Lattarini wrote:
Fine as well. And of curse, if you want to speed thing up and have more
control on the final result, feel free to shepherd the pending
Stefano Lattarini wrote:
Fine as well. And of curse, if you want to speed thing up and have more
control on the final result, feel free to shepherd the pending patches to
the agreed form ;-) -- which if I'm not mistaken is:
- make the series consist of only two patches, one introducing the
On 2013-02-08 09:45, Peter Rosin wrote:
Stefano Lattarini wrote:
Fine as well. And of curse, if you want to speed thing up and have more
control on the final result, feel free to shepherd the pending patches to
the agreed form ;-) -- which if I'm not mistaken is:
- make the series consist
Stefano Lattarini wrote:
Fine as well. And of curse, if you want to speed thing up and have more
control on the final result, feel free to shepherd the pending patches to
the agreed form ;-) -- which if I'm not mistaken is:
- make the series consist of only two patches, one introducing the
On 02/08/2013 05:13 AM, Miles Bader wrote:
Hmm, if that's the case, then I think canon is the wrong term to
use, as it typically implies that the result is still in the same
domain as the input.
Suggestions for a better name then?
Dunno... something like RELDIR_SYM would make sense ...
On 02/08/2013 10:11 AM, Peter Rosin wrote:
On 2013-02-08 09:45, Peter Rosin wrote:
Stefano Lattarini wrote:
Fine as well. And of curse, if you want to speed thing up and have more
control on the final result, feel free to shepherd the pending patches to
the agreed form ;-) -- which if I'm
On 02/05/2013 02:01 AM, Miles Bader wrote:
%...% seems nice to me.
I'm fine to settle for that (see my reply to last mail from Peter for
more details).
Incidentally, given the name, I assume the name reldir always refers
to a relative path? What is it relative to again?
The path of the
... and canon_reldir means the same thing, except canonicalized?
Yes, canonicalized in a sense quite specific to Automake:
http://www.gnu.org/software/automake/manual/automake.html#Canonicalization
So, for example, if %reldir% expands to 'foo/bar-baz.d', '%canon-reldir%'
will expand to
Hmm, if that's the case, then I think canon is the wrong term to
use, as it typically implies that the result is still in the same
domain as the input.
Suggestions for a better name then?
Dunno... something like RELDIR_SYM would make sense ... it's a
symbol corresponding to RELDIR...
On 02/05/2013 12:03 AM, Peter Rosin wrote:
On 2013-02-04 19:11, Stefano Lattarini wrote:
On 02/04/2013 06:33 PM, Eric Blake wrote:
So they aren't quite affected by configure, but they are dependent on
relative location, just like existing substitutions like @top_srcdir@
are dependent on
... and canon_reldir means the same thing, except canonicalized?
Yes, canonicalized in a sense quite specific to Automake:
http://www.gnu.org/software/automake/manual/automake.html#Canonicalization
So, for example, if %reldir% expands to 'foo/bar-baz.d', '%canon-reldir%'
will expand to
On 02/05/2013 02:01 AM, Miles Bader wrote:
%...% seems nice to me.
I'm fine to settle for that (see my reply to last mail from Peter for
more details).
Incidentally, given the name, I assume the name reldir always refers
to a relative path? What is it relative to again?
The path of the
On 02/07/2013 10:52 AM, Miles Bader wrote:
... and canon_reldir means the same thing, except canonicalized?
Yes, canonicalized in a sense quite specific to Automake:
http://www.gnu.org/software/automake/manual/automake.html#Canonicalization
So, for example, if %reldir% expands to
On 02/04/2013 12:10 AM, Peter Rosin wrote:
On 2013-02-03 21:42, Stefano Lattarini wrote:
I've pushed the promised patches to the rewindable branch
'experimental/preproc' (based off of maint). I'll also soon
send them to the list to simplify review (I will drop the
bug tracker from CC:, to
On 02/04/2013 10:35 AM, Peter Rosin wrote:
On 2013-02-04 00:10, Peter Rosin wrote:
On 2013-02-03 21:42, Stefano Lattarini wrote:
I've pushed the promised patches to the rewindable branch
'experimental/preproc' (based off of maint). I'll also soon
send them to the list to simplify review (I
On 2013-02-04 12:23, Stefano Lattarini wrote:
On 02/04/2013 12:10 AM, Peter Rosin wrote:
On 2013-02-03 21:42, Stefano Lattarini wrote:
I've pushed the promised patches to the rewindable branch
'experimental/preproc' (based off of maint). I'll also soon
send them to the list to simplify
On 2013-02-04 14:43, Stefano Lattarini wrote:
On 02/04/2013 01:04 PM, Peter Rosin wrote:
I {{think}} this one will be the easiest on us of all.
BTW, that was a mix of on us all and on all of us, if
anyone didn't notice...
I tend to agree (but see Peter Johansson's proposal to use
On 02/04/2013 03:06 PM, Peter Rosin wrote:
On 2013-02-04 14:43, Stefano Lattarini wrote:
On 02/04/2013 01:04 PM, Peter Rosin wrote:
I {{think}} this one will be the easiest on us all.
I tend to agree (but see Peter Johansson's proposal to use
{AM_RELDIR} instead; what do you think about it?)
On 2013-02-04 19:11, Stefano Lattarini wrote:
On 02/04/2013 06:33 PM, Eric Blake wrote:
So they aren't quite affected by configure, but they are dependent on
relative location, just like existing substitutions like @top_srcdir@
are dependent on relative location.
Yes, but they are dependent
%...% seems nice to me.
I don't think typability should be a prime factor in deciding,
especially such trivial issues such as shifted-characters (like 75% of
punctuation in Makefiles is shifted on most keyboards); readability is
_much_ more important (and readability in many cases means not too
On 2013-02-04 00:10, Peter Rosin wrote:
On 2013-02-03 21:42, Stefano Lattarini wrote:
I've pushed the promised patches to the rewindable branch
'experimental/preproc' (based off of maint). I'll also soon
send them to the list to simplify review (I will drop the
bug tracker from CC:, to avoid
On 02/04/2013 12:10 AM, Peter Rosin wrote:
On 2013-02-03 21:42, Stefano Lattarini wrote:
I've pushed the promised patches to the rewindable branch
'experimental/preproc' (based off of maint). I'll also soon
send them to the list to simplify review (I will drop the
bug tracker from CC:, to
On 2013-02-04 12:23, Stefano Lattarini wrote:
On 02/04/2013 12:10 AM, Peter Rosin wrote:
On 2013-02-03 21:42, Stefano Lattarini wrote:
I've pushed the promised patches to the rewindable branch
'experimental/preproc' (based off of maint). I'll also soon
send them to the list to simplify
On 2013-02-04 12:33, Stefano Lattarini wrote:
On 02/04/2013 10:35 AM, Peter Rosin wrote:
Not sure what to do about it, or if it matters...
It does IMHO, since the failure you pointed out, albeit easy to
work around, wouldn't be very obvious to diagnose, from the point
of view of a
On 2/4/13 9:33 PM, Stefano Lattarini wrote:
What about doubling the curly braces? As in '{{RELDIR}}'.
Would that be tolerable? Other possibilities (none particularly
pleasant either, IMHO):
{+RELDIR+}
{:RELDIR:}
{.RELDIR.}
{-RELDIR-}
Other proposals?
Using Automake's namespace,
On 02/04/2013 01:44 PM, Peter Johansson wrote:
On 2/4/13 9:33 PM, Stefano Lattarini wrote:
What about doubling the curly braces? As in '{{RELDIR}}'.
Would that be tolerable? Other possibilities (none particularly
pleasant either, IMHO):
{+RELDIR+}
{:RELDIR:}
{.RELDIR.}
On 02/04/2013 01:04 PM, Peter Rosin wrote:
On 2013-02-04 12:33, Stefano Lattarini wrote:
On 02/04/2013 10:35 AM, Peter Rosin wrote:
Not sure what to do about it, or if it matters...
It does IMHO, since the failure you pointed out, albeit easy to
work around, wouldn't be very obvious to
On 2013-02-04 14:43, Stefano Lattarini wrote:
On 02/04/2013 01:04 PM, Peter Rosin wrote:
I {{think}} this one will be the easiest on us of all.
BTW, that was a mix of on us all and on all of us, if
anyone didn't notice...
I tend to agree (but see Peter Johansson's proposal to use
On 02/04/2013 03:06 PM, Peter Rosin wrote:
On 2013-02-04 14:43, Stefano Lattarini wrote:
On 02/04/2013 01:04 PM, Peter Rosin wrote:
I {{think}} this one will be the easiest on us all.
I tend to agree (but see Peter Johansson's proposal to use
{AM_RELDIR} instead; what do you think about it?)
On 02/04/2013 10:19 AM, Stefano Lattarini wrote:
Because it would mix up very different concepts: a '@...@' substitution
is meant for something that depends on configure-time check (or at
least from code in configure), and is substituted the same in *every*
Makefile and makefile fragment;
Not
On 02/04/2013 06:33 PM, Eric Blake wrote:
On 02/04/2013 10:19 AM, Stefano Lattarini wrote:
Because it would mix up very different concepts: a '@...@' substitution
is meant for something that depends on configure-time check (or at
least from code in configure), and is substituted the same in
tags 13524 + patch
thanks
[+cc automake-patches]
Reference:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13524
On 01/28/2013 12:38 AM, Peter Rosin wrote:
Hi Stefano,
On 2013-01-27 20:21, Stefano Lattarini wrote:
This time with documentation and a NEWS entry. I also fixed the case
of
tags 13524 + patch
thanks
[+cc automake-patches]
Reference:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13524
On 01/28/2013 12:38 AM, Peter Rosin wrote:
Hi Stefano,
On 2013-01-27 20:21, Stefano Lattarini wrote:
This time with documentation and a NEWS entry. I also fixed the case
of
On 02/01/2013 04:18 PM, Bert Wesarg wrote:
Hi all,
On Mon, Jan 28, 2013 at 12:38 AM, Peter Rosin p...@lysator.liu.se wrote:
Hi Stefano,
On 2013-01-27 20:21, Stefano Lattarini wrote:
This time with documentation and a NEWS entry. I also fixed the case
of including something above the
Hi Peter.
On 01/27/2013 01:54 AM, Peter Rosin wrote:
[SNIP]
Zapping the NIH part reduced the code size significantly (the patch
is now short, sweet and unintrusive again) so I'm posting a new version.
After all, it's a new day, right?
I hope it's ok to use File::Spec-abs2rel () in
On 2013-01-25 17:03, Peter Rosin wrote:
On 2013-01-24 13:22, Peter Rosin wrote:
On 2013-01-23 16:08, Stefano Lattarini wrote:
On 01/23/2013 03:34 PM, Peter Rosin wrote:
On 2013-01-23 13:45, Stefano Lattarini wrote:
*snip*
Too much automagic here IMO. We'd better have two distinct subst, one
On 2013-01-23 16:08, Stefano Lattarini wrote:
On 01/23/2013 03:34 PM, Peter Rosin wrote:
On 2013-01-23 13:45, Stefano Lattarini wrote:
*snip*
Too much automagic here IMO. We'd better have two distinct subst, one for
the real directory name, and one for the directory name canonicalized
for
Hello Miles, thanks for the feedback.
On 01/23/2013 07:54 AM, Miles Bader wrote:
Stefano Lattarini stefano.lattar...@gmail.com writes:
E.g., if I have a directory foo that has sources etc, and builds
some specific targets, then I can isolate the automake stuff for foo
by using an include file
Hi Peter, thanks for the patch.
Not sure if you are in the mood (or have the time) to engage in a
discussion about it, but here my review anyway. Even if you are not
going to work on this patch anymore, a review will still be useful
as a reference to me or other developers in the future.
On
On 2013-01-23 13:45, Stefano Lattarini wrote:
Hi Peter, thanks for the patch.
Not sure if you are in the mood (or have the time) to engage in a
discussion about it, but here my review anyway. Even if you are not
going to work on this patch anymore, a review will still be useful
as a
On 01/23/2013 03:34 PM, Peter Rosin wrote:
On 2013-01-23 13:45, Stefano Lattarini wrote:
Hi Peter, thanks for the patch.
Not sure if you are in the mood (or have the time) to engage in a
discussion about it, but here my review anyway. Even if you are not
going to work on this patch anymore,
On 2013-01-22 10:18, Stefano Lattarini wrote:
[+cc bug-automake, so that we won't forget about the issue]
[future replies should drop the automake list]
On 01/22/2013 02:22 AM, Miles Bader wrote:
Stefano Lattarini stefano.lattar...@gmail.com writes:
The best solution is on the user-side
Stefano Lattarini stefano.lattar...@gmail.com writes:
E.g., if I have a directory foo that has sources etc, and builds
some specific targets, then I can isolate the automake stuff for foo
by using an include file foo/Makefile.am.inc or something, and then
putting an appropriate include in the
[+cc bug-automake, so that we won't forget about the issue]
[future replies should drop the automake list]
On 01/22/2013 02:22 AM, Miles Bader wrote:
Stefano Lattarini stefano.lattar...@gmail.com writes:
The best solution is on the user-side IMHO: fix the build system to
use less (ideally
47 matches
Mail list logo
