Hello automakers.
JFTR, a final word on this thread ...
On Wednesday 12 January 2011, Stefano Lattarini wrote:
And more than this -- brace yourself -- I'm starting to think that
automake should *really* start supporting *only* GNU make (at least
from version 3.75 or so).
When I advanced my
* On Sat, Jan 15, 2011 at 12:08 AM, Paul Smith psm...@gnu.org wrote:
* On Fri, 2011-01-14 at 19:57 +0100, Ralf Wildenhues wrote:
http://gittup.org/tup/build_system_rules_and_algorithms.pdf.
No idea whether they are standardized somehow or somewhere.
On Mon, 2011-01-17 at 17:28 +0100, Steffen Dettmer wrote:
When having a source three constructed of several (sub-)
packages, how does a Beta-Build system looks like? Could there be
tupfiles including sub-tup-files?
What influence has the choice of a Beta-Build to the
maintainability of such
On Mon, Jan 17, 2011 at 6:31 PM, Paul Smith psm...@gnu.org wrote:
On Mon, 2011-01-17 at 17:28 +0100, Steffen Dettmer wrote:
When having a source three constructed of several (sub-)
packages, how does a Beta-Build system looks like? Could there be
tupfiles including sub-tup-files?
What
From my perspective as a maintainer of the reference implementation of
NTP, I value make portability and would be disappointed to see
Automake become GNU-make-specific. We strive to make our tarballs
easy to build and install on a wide variety of new and old systems.
As an example, until a little
On Thu, Jan 13, 2011 at 8:39 PM, stefano.lattar...@gmail.com wrote:
``I truly dislike the idea of not keeping configuration and build
steps separated.''
Maybe I'd just like a system that *allows* me to keep configuration
and build steps clerarly distinct if I want to. Yes, that would
be
On Fri, 14 Jan 2011, Ralf Wildenhues wrote:
(That, by the way, is what nobody ever tells you when they point you to
the Recursive Make Considered Harmful paper: that walking the full
dependency tree is more expensive than walking a factorized one. Sure,
you need to keep the toplevel deps up to
On Friday 14 January 2011, Steffen Dettmer wrote:
On Thu, Jan 13, 2011 at 8:39 PM, stefano.lattar...@gmail.com wrote:
``I truly dislike the idea of not keeping configuration and build
steps separated.''
Maybe I'd just like a system that *allows* me to keep configuration
and build
* Guido Draheim wrote on Thu, Jan 13, 2011 at 08:55:20PM CET:
By the way, I would find it more interesting to see some
automake-replacement that allows GNU-make extensions and
compiles them down to standard make as far as possible...
Generally, I wouldn't, as I don't like the idea of
Hi Bob,
* Bob Friesenhahn wrote on Fri, Jan 14, 2011 at 04:04:35PM CET:
In addition to the above, Automake should be supplying enough explicit rule
information (pertaining to the actual needs of the current project) that the
underlying build tool should not have to go off in the weeds and try
Ralf,
Where do these terms 'alpha' and 'beta' build system originate from?
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
* Bob Friesenhahn wrote on Fri, Jan 14, 2011 at 07:55:17PM CET:
Where do these terms 'alpha' and 'beta' build system originate from?
I've read them in
http://gittup.org/tup/build_system_rules_and_algorithms.pdf.
No idea whether they are standardized somehow or somewhere.
Cheers,
Ralf
On Fri, 2011-01-14 at 19:57 +0100, Ralf Wildenhues wrote:
* Bob Friesenhahn wrote on Fri, Jan 14, 2011 at 07:55:17PM CET:
Where do these terms 'alpha' and 'beta' build system originate from?
I've read them in
http://gittup.org/tup/build_system_rules_and_algorithms.pdf.
No idea whether
hmm, is the tupfile syntax really as horrible as it looks?
[ from the examples page:
: hello.c | gcc -Wall -c hello.c -o hello.o | hello.o
]
-miles
--
Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.
* Stefano Lattarini wrote on Wed, Jan 12, 2011 at 09:58:36PM CET:
On Wednesday 12 January 2011, Ralf Wildenhues wrote:
The upsides are obvious.
If I'm not deluding myself, most of the contents of my proposal were
aimed at showing why I believe that requiring GNU make is a reasonable
and
Good day.
I'll throw my humble userish $0.02 in here.
First of all, i like the idea of autotools working in any POSIX
enviroment, requiring a set of tools that is everywhere by definition.
Because when for example i try to compile my project in hostile
environment with suspicious admins that
On Thu, Jan 13, 2011 at 3:39 AM, Bob Friesenhahn
bfrie...@simple.dallas.tx.us wrote:
While GNU make is a really good 'make' program, I think that 'make' in
general is a flawed concept.
Could you please explain this a bit?
I like the `make' concept; in some situations I even love it.
One
On Wed, Jan 12, 2011 at 10:36 PM, stefano.lattar...@gmail.com wrote:
- I think that keeping configuration and build steps separated is
a very good idea.
Do you mean this is a good idea in the context of todays systems
- or -
Do you mean this is good idea in general and could be a design
On Thursday 13 January 2011, Юрий Пухальский wrote:
Good day.
I'll throw my humble userish $0.02 in here.
First of all, i like the idea of autotools working in any POSIX
enviroment, requiring a set of tools that is everywhere by definition.
Because when for example i try to compile my
2011/1/13 Stefano Lattarini stefano.lattar...@gmail.com:
On Thursday 13 January 2011, Юрий Пухальский wrote:
Good day.
I'll throw my humble userish $0.02 in here.
First of all, i like the idea of autotools working in any POSIX
enviroment, requiring a set of tools that is everywhere by
On Thu, 13 Jan 2011, Steffen Dettmer wrote:
On Thu, Jan 13, 2011 at 3:39 AM, Bob Friesenhahn
bfrie...@simple.dallas.tx.us wrote:
While GNU make is a really good 'make' program, I think that 'make' in
general is a flawed concept.
Could you please explain this a bit?
Make depends entirely on
[About GNU make]
GNU make is a basic component of the GNU system, actively maintained and
developed, well documented, and required by other very important projects
(Linux Kernel and Git DVCS, for example).
GNU make is very portable, easy to compile, and fully bootstrapping (its
On Thu, 13 Jan 2011, Guido Draheim wrote:
* ClearCase - ships clearmake integrated with the build systems.
and there are sure some other build systems that have a frontend to
the user allowing for makefiles as the backend.
FYI, ClearCase's clearmake is actually based on GNU make source code.
* Bob Friesenhahn wrote on Thu, Jan 13, 2011 at 07:50:08PM CET:
Regardless, 'make's use of timestamps based on simple newer than
analsys is not very robust in our real world.
That may be true, but this issue is completely orthogonal to whether
Automake caters to non-GNU make implementations or
On Thursday 13 January 2011, Ralf Wildenhues wrote:
* Stefano Lattarini wrote on Wed, Jan 12, 2011 at 09:58:36PM CET:
On Wednesday 12 January 2011, Ralf Wildenhues wrote:
The upsides are obvious.
If I'm not deluding myself, most of the contents of my proposal were
aimed at showing why
Am 12.01.2011 19:01, schrieb Stefano Lattarini:
GNU make is a basic component of the GNU system, actively maintained and
GNU make is very portable, easy to compile, and fully bootstrapping
GNU make is the default make program on GNU/Linux (okay, we're in
GNU make is readily available in
On Thu, 13 Jan 2011, Ralf Wildenhues wrote:
* Bob Friesenhahn wrote on Thu, Jan 13, 2011 at 07:50:08PM CET:
Regardless, 'make's use of timestamps based on simple newer than
analsys is not very robust in our real world.
That may be true, but this issue is completely orthogonal to whether
* Guido Draheim wrote on Thu, Jan 13, 2011 at 08:25:05PM CET:
But GNU Make on its own has a very large feature-set that is strong enough to
be a build-system on its own. You don't need much of autoconf/automake
anymore!!
Exactly. quagmire is one (other) implementation of that. I don't
On Thursday 13 January 2011, Steffen Dettmer wrote:
On Wed, Jan 12, 2011 at 10:36 PM, stefano.lattar...@gmail.com wrote:
- I think that keeping configuration and build steps separated is
a very good idea.
Do you mean this is a good idea in the context of todays systems
- or -
Do you
Am 13.01.2011 19:50, schrieb Bob Friesenhahn:
On Thu, 13 Jan 2011, Guido Draheim wrote:
* ClearCase - ships clearmake integrated with the build systems.
and there are sure some other build systems that have a frontend to
the user allowing for makefiles as the backend.
FYI, ClearCase's
On Thu, 2011-01-13 at 12:50 -0600, Bob Friesenhahn wrote:
FYI, ClearCase's clearmake is actually based on GNU make source code.
At least it was back when I was using it.
Not that it matters but this is not _quite_ true... otherwise clearmake
would fall under the GPL.
What clearmake used to do
On Wed, Jan 12, 2011 at 07:01:47PM +0100, Stefano Lattarini wrote:
To be honest, I'm starting to agree with Ralf more and more on these
issues; i.e., just ... require a decent make ;-).
And more than this -- brace yourself -- I'm starting to think that
automake should *really* start
Hello Roger.
I take up on a tangential issue here ...
On Thursday 13 January 2011, Roger Leigh wrote:
[MEGA-CUT]
I would find it useful to make use of more advanced GNU
make-specific features on occasion, without automake complaining!
For this, I think having a new `portability-make'
On Thu, 2011-01-13 at 20:38 +0100, Ralf Wildenhues wrote:
* Bob Friesenhahn wrote on Thu, Jan 13, 2011 at 08:32:01PM CET:
On Thu, 13 Jan 2011, Ralf Wildenhues wrote:
You can implement hash-based dependencies inside GNU make if you like.
Or another make. Maybe someone has even done so
On 1/13/11, Ralf Wildenhues ralf.wildenh...@gmx.de wrote:
make is a bit flawed for real large projects because it always walks
the whole dependency graph, unlike beta build systems who use a notify
daemon and a database to only walk subgraphs known to be outdated.
How big is real large? GCC
* NightStrike wrote on Fri, Jan 14, 2011 at 05:12:46AM CET:
On 1/13/11, Ralf Wildenhues wrote:
make is a bit flawed for real large projects because it always walks
the whole dependency graph, unlike beta build systems who use a notify
daemon and a database to only walk subgraphs known to be
[Adding automake@gnu.org, dropping bug-autom...@gnu.org]
References:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7824
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7670
On Wednesday 12 January 2011, Юрий Пухальский wrote:
Aye, looks like it.
I have no objections whatsoever, i just need
2011/1/12 Stefano Lattarini stefano.lattar...@gmail.com:
I'm starting to think that
automake should *really* start supporting *only* GNU make (at least
from version 3.75 or so).
I think also bash, gcc and most GNU tools are widely avialable.
They could be built using an old fixed automake.
But
* Stefano Lattarini wrote on Wed, Jan 12, 2011 at 07:01:47PM CET:
And more than this -- brace yourself -- I'm starting to think that
automake should *really* start supporting *only* GNU make (at least
from version 3.75 or so).
If you want support for this, then you need to discuss away
On Wednesday 12 January 2011, Steffen Dettmer wrote:
2011/1/12 Stefano Lattarini stefano.lattar...@gmail.com:
I'm starting to think that
automake should *really* start supporting *only* GNU make (at least
from version 3.75 or so).
I think also bash, gcc and most GNU tools are widely
On Wednesday 12 January 2011, Ralf Wildenhues wrote:
* Stefano Lattarini wrote on Wed, Jan 12, 2011 at 07:01:47PM CET:
On Wednesday 12 January 2011, Юрий Пухальский wrote:
Aye, looks like it.
I have no objections whatsoever, i just need some method to make it
work, because it's my
On Wednesday 12 January 2011, Ralf Wildenhues wrote:
* Stefano Lattarini wrote on Wed, Jan 12, 2011 at 07:01:47PM CET:
And more than this -- brace yourself -- I'm starting to think that
automake should *really* start supporting *only* GNU make (at least
from version 3.75 or so).
On Wednesday 12 January 2011, Xochitl Lunde wrote:
But let me rephrase the critique in a poignant way: if you want to
require GNU make anyway, what is your rational to not use quagmire
instead of Automake?
You mean this?
http://code.google.com/p/quagmire/
Well, the fact
Xochitl Lunde xochitl_lu...@tripplite.com writes:
I see that I can get the source, but I don't want to have to compile this
thing if it's not purely script based.
AFAIK, quagmire requires nothing other than GNU make (that was, I guess,
the point of it)...
Also when I go to quagmire-discuss,
On 01/12/2011 12:01 PM, Stefano Lattarini wrote:
[About the purpose or spirit of Automake]
Automake is about much more than just portability to different make
implementations; it's about:
No. The philosophy of the autotools has always been to make the end
users life easier, in part by
On Wed, 12 Jan 2011, Stefano Lattarini wrote:
Those you list above are very good *practical* reasons not to use quagmire
(and the very fact that it took me 3 minutes to find that page with google
was IMHO already a clear indicator that the project is dead in practice).
The answer I was
On Wed, 12 Jan 2011, Peter O'Gorman wrote:
On 01/12/2011 12:01 PM, Stefano Lattarini wrote:
[About the purpose or spirit of Automake]
Automake is about much more than just portability to different make
implementations; it's about:
No. The philosophy of the autotools has always been to
47 matches
Mail list logo
