Request for stable, automated build process

BrendaWang brenda_wang at openmoko.com
Mon May 12 04:32:34 CEST 2008


Dear all:
After one weeks great work.
Julien had release the new toolchain release.
please take a look of this Page.

 http://wiki.openmoko.org/wiki/Toolchain



Bobby Martin ??:
>
>     From: Ian Darwin <ian at darwinsys.com <mailto:ian at darwinsys.com>>
>     I did mention when I jumped in that I was talking about a slightly
>     different problem than what you seem to be trying to solve. That
>     said...
>
>         Storing your MD5s will let you know *if* you are repeating a
>         build. It will not (reasonably) let you repeat a build.
>
>
>     You completely misunderstood what I said. Storing the file name,
>     URL *and* its MD5 lets you be sure you are able to reproduce the
>     build. And it's the only way you can (well, we actually use SHA's
>     and RMD's in addition to MD5's).
>
>
> If I misunderstood it, I still do. MD5 absolutely will not help you 
> reproduce a build. It will only help you verify that your procedure 
> (whatever it is) retrieved the same files. It won't help you find the 
> correct file if the file you got was wrong.
>
>
>     It does not guarantee to build *exactly* the same binary, but you
>     can *never ever* make that guarantee in general because of changes
>     to shared libraries (in the Java world you have a greater chance,
>     but even then,
>     even the smallest point upgrade to the JDK could in theory change
>     the generated .class files), so there is really no point whatever
>     using MD5's on generated binaries. None. I have no idea why Hudson
>     bothers, if that's what it's using them for.
>
>
>         You need some way of identifying the file you want to build
>         *to the revision control system* (so you can download that
>         version) if you want repeatable builds.
>
>
>     In the case I'm talking about - where there are about 5,000
>     different external programs from about 2,500 different sources -
>     you don't even think about going to the revision control system (6
>     or 8 different services over 2,000 different hosts). You can ONLY
>     think in terms of
>     ftp/http download of version-numbered tarballs. Period.
>
>
> No, you MOSTLY think in terms of ftp/http download. For the projects 
> on which you're doing work (at least) you absolutely go to the 
> revision control system.
>
> Are we talking about the same thing? I'm talking about a repeatable 
> build so I can do development work, modifying existing code. To do 
> that, you'd better work with the revision control system. Even if you 
> don't have submit access (which the vast majority of devs probably 
> shouldn't have), in some cases you have a RCS that supports creating 
> smart diffs that you can send to someone to review & submit trivially 
> (e.g. git or darcs) and in other cases you almost certainly want to 
> submit a patch from the latest possible revision.
>
>
>         MD5s sound nice to verify, if you don't trust your revision
>         control system (or perhaps the admins ;-)
>
>
>     See above for why revision control is completely irrelevant to us.
>
>
> Who is 'us'?
>
> Bobby
>
> -- 
> If it doesn't make you smile, you're doing something wrong.
> ------------------------------------------------------------------------
>
> _______________________________________________
> Openmoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>   





More information about the community mailing list