Re: Initial LLVM/clang patch

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

hi,

>> > > > 2. Doing this in src means that no binary packages for the toolchain.
>> > > 
>> > > why?
>> > 
>> > pkgsrc makes one for you by doing "make package". I can take the result,
>> > optionally sign it, and move it to any machine I want and use it there.
>> 
>> Nothing stops you from that with the clang package. The patch provides
>> two different things that pkgsrc can't easily replicate:
>> 
>> (1) Building a native clang compiler for running on NetBSD. Even if the
>> host system you have is not NetBSD.
>> 
>> (2) Building a cross compiler and integrating it into the NetBSD tree.
>> 
>> This is not about providing an external toolchain, but about getting
>> clang to the point where it can be fully used as normal in-tree
>> toolchain. At that point or when it is far enough, it is perfectively
>> sensible to do a real import. I just want to avoid the trouble of
>> keeping the version synchronised or people committing local patches
>> without bringing them up upstream first etc. As in: I want to avoid a
>> divergenting development line.
> 
> Aha, OK, so we're coming at this from different viewpoints.  My view
> is that if this external toolchain is not far enough along to be
> committed to the tree, then it doesn't belong there.  If it doesn't
> belong in-tree, special custom knobs to download it and build it also
> do not belong in the tree.  If we can use external packages (via a
> clang-devel fast-moving pkgsrc package, for example), then let's use
> that. Yes, we'd need to add a "svn co" download method, but pkgsrc
> would benefit from that too.

IMO, there's no problem to have work-in-progress stuff in any
(possibly ugly or even wrong) shape which is easy for the interested
developer to work on, unless it hurts others.

YAMAMOTO Takashi