Re: CONS specs update?

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 b=
uild=20
into separate steps - if only to simplify debugging... But for me, the mo=
st=20
important difference is that "normal" library formats come with a well-kn=
own=20
tool to make them (whether a compiler, libtool wrapper or whatever), whil=
e=20
Microsoft more-or-less describes steps to make a signed assembly but give=
s no=20
hint how to automate the recipe. That's why the task makes a good stress =
test=20
for a build tool (I've seen the recipe implemented in NAnt + custom C# co=
de -=20
it works, but is unbelievably awful).

=09Bye
=09=09Vasek



_______________________________________________
[email protected]
http://lists.gnu.org/mailman/listinfo/cons-discuss
Cons URL: http://www.dsmit.com/cons/