cons-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CONS specs update?


From: Vaclav Barta
Subject: Re: CONS specs update?
Date: Mon, 28 Jun 2004 21:21:20 +0200
User-agent: KMail/1.4.3

On Friday 25 June 2004 05:53 pm, H. S. Teoh wrote:
> > > Ideally, though, I'd prefer to treat them as separate steps. I don't
> > > like the idea of a file modified in-place (i.e., processingtool.pl
> > > reads in abc.c and writes a modified version replacing abc.c).
> > Then prepare to build across directories - there are steps (adding
> > a key to a .NET DLL, for example) which *must not* change the name of the
> > file.
> What could be done in this case is to always build the DLL from
> scratch whenever it is to be updated. (We then consider adding all the
Well, yes, that's possible...

> keys as a single step.) I don't see how this is different from
> building .a or .so libraries; those formats also support incremental
> updates, but (currently) the plan is to always rebuild them from
> scratch for the sake of build reproducibility.
Not from scratch: from object files. IMHO it's very useful to split the build 
into separate steps - if only to simplify debugging... But for me, the most 
important difference is that "normal" library formats come with a well-known 
tool to make them (whether a compiler, libtool wrapper or whatever), while 
Microsoft more-or-less describes steps to make a signed assembly but gives no 
hint how to automate the recipe. That's why the task makes a good stress test 
for a build tool (I've seen the recipe implemented in NAnt + custom C# code - 
it works, but is unbelievably awful).

        Bye
                Vasek





reply via email to

[Prev in Thread] Current Thread [Next in Thread]