Reference:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378
On 01/07/2013 09:08 PM, Stefano Lattarini wrote:
Severity: wishlist
Inspired from Automake-NG commit 'v1.12.1-313-g14fe163' of 2012-06-07,
[ng] subdir-objects: enable unconditionally.
The fact that Automake-generated Makefiles
On 01/08/2013 10:57 AM, Peter Breitenlohner wrote:
On Mon, 7 Jan 2013, Stefano Lattarini wrote:
Alas, since this also means changing the default behaviour of Automake
('subdir-objects' is not enabled by default, sadly), this means the
transition path will be less smooth than I'd like. Here
On 01/08/2013 11:35 AM, Stefano Lattarini wrote:
this warning (given when there are C - or other? - sources in subdirs)
should also mention the need to use AM_PROG_CC_C_O.
Agreed.
Actually, the warning about a missing AM_PROG_CC_C_O will be automatically
given once the user has added
Hi Nick.
On 01/08/2013 03:53 PM, Nick Bowler wrote:
On 2013-01-08 13:17 +0100, Stefano Lattarini wrote:
Actually, the warning about a missing AM_PROG_CC_C_O will be automatically
given once the user has added 'subdir-objects' to the AUTOMAKE_OPTIONS.
- the user sees the warning about
On 01/08/2013 08:15 AM, Stefano Lattarini wrote:
That would be overkill, since AM_PROG_CC_C_O is only required by
projects doing C compilation. Also, IIRC, that macro needs to be
called after AC_PROG_CC, while AM_INIT_AUTOMAKE is typically invoked
before AC_PROG_CC.
But with m4, you can
[+cc automake-patches]
Reference:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#44
On 01/08/2013 05:00 PM, Nick Bowler wrote:
On 2013-01-08 16:15 +0100, Stefano Lattarini wrote:
On 01/08/2013 03:53 PM, Nick Bowler wrote:
[...]
I don't think AM_PROG_CC_C_O is optional at all when
On 01/08/2013 04:29 PM, Eric Blake wrote:
On 01/08/2013 08:15 AM, Stefano Lattarini wrote:
That would be overkill, since AM_PROG_CC_C_O is only required by
projects doing C compilation. Also, IIRC, that macro needs to be
called after AC_PROG_CC, while AM_INIT_AUTOMAKE is typically invoked
On 2013-01-08 16:15, Stefano Lattarini wrote:
That would be overkill, since AM_PROG_CC_C_O is only required by
projects doing C compilation.
Hi,
However, a notorious C++ compiler from Redmond is inferior also in its
C++ mode and would benefit from an AM_PROG_CXX_C_O variant. If the
meat of
On 2013-01-08 20:27, Stefano Lattarini wrote:
On 01/08/2013 04:29 PM, Eric Blake wrote:
On 01/08/2013 08:15 AM, Stefano Lattarini wrote:
In addition, AM_PROG_CC_C_O is not required by
projects that don't care about catering to inferior compilers.
How much speed penalty and configure bloat
On 2013-01-08 22:42, Stefano Lattarini wrote:
On 01/08/2013 10:06 PM, Peter Rosin wrote:
On 2013-01-08 16:15, Stefano Lattarini wrote:
That would be overkill, since AM_PROG_CC_C_O is only required by
projects doing C compilation.
Hi,
However, a notorious C++ compiler from Redmond is
On 01/08/2013 11:03 PM, Peter Rosin wrote:
[BIG SNIP]
Then again, in the longer term, wouldn't it be better to provide a
(GNU or non-GNU) package meant to wrap all this MSVC incompatibilities
in a secluded place, instead of having Automake chase all this
intricacies with mixed fortune?
Severity: wishlist
Inspired from Automake-NG commit 'v1.12.1-313-g14fe163' of 2012-06-07,
[ng] subdir-objects: enable unconditionally.
The fact that Automake-generated Makefiles place compiled object files in
he current directory by default, also when the corresponding source file
is in a
Hi Peter, thanks for the feedback.
On 01/07/2013 10:55 PM, Peter Johansson wrote:
On 1/8/13 6:08 AM, Stefano Lattarini wrote:
Severity: wishlist
Inspired from Automake-NG commit 'v1.12.1-313-g14fe163' of 2012-06-07,
[ng] subdir-objects: enable unconditionally.
The fact that
Hi Stefano,
On 01/08/2013 08:18 AM, Stefano Lattarini wrote:
Actually no, the change tend to be much more extensive (as they've been
between 1.12 and 1.13, not always smoothly or pleasantly). Maybe, to make
this clear, we should name release a 2.0 version instead of a 1.14?
No need, IMHO.
14 matches
Mail list logo
