[llvm-commits] [lld] r158336 - in /lld/trunk: include/lld/ReaderWriter/WriterMachO.h lib/ReaderWriter/MachO/CMakeLists.txt lib/ReaderWriter/MachO/MachOFormat.hpp lib/ReaderWriter/MachO/ReferenceKinds.cpp lib/ReaderWriter/MachO/ReferenceKinds.h li

[Chandler Carruth]

On Mon, Jun 11, 2012 at 5:19 PM, Nick Kledzik <kledzik at apple.com> wrote:

>
> On Jun 11, 2012, at 4:02 PM, Chandler Carruth wrote:
>
> On Mon, Jun 11, 2012 at 3:53 PM, Nick Kledzik <kledzik at apple.com> wrote:
>
>> Author: kledzik
>> Date: Mon Jun 11 17:53:15 2012
>> New Revision: 158336
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=158336&view=rev
>> Log:
>> Move implementation of WriterOptionsMachO to its own file. Reduced
>> redundant
>> ivars in WriterOptionsMachO instead have its methods compute ivar
>> interactions.
>> Refactor mach-o Reference Kinds and introduce abstract class KindHandler.
>> Split up StubAtoms.hpp by architecture.  Add support for 32-bit x86 stubs.
>>
>
> This really feels like it should be split across separate commits to make
> code review more tractable Nick...
>
> You have several changes which are no-functionality changed, just moving
> code around. Those should always be separate. They can be reviewed super
> easily, and that allows the commits which actually make changes to be
> reviewed with a precise diff.
>
> You actually have the different steps in your log message: each sentence
> feels like it should have been its own distinct commit.
>
>
> For reference, I mention this because several people have come to me
> expressing interest in getting involved with lld, but have struggled to
> review the existing code and start reviewing commits because the commits
> were very lumped together.
>
>
> I understand simple, modular commits for a mature, large code base with
> lots of developers involved.
>
> But, lld is still very much in its infancy.  These commits are more like
> check-points.   I expect plenty more refactoring churn before lld is stable
> enough to open it up to more contributors.
>

I think that you're creating a chicken/egg situation. I think that you have
to act as-if there are other contributors in order to gain them. If you
simply checkpoint work and convenient points, that
will disincentivize anyone from getting involved because they have no idea
what's going on.

I think it's important to get more people involved *during* the infancy of
the project rather than afterward. That's the whole point of doing open
development as part of a community. =/

Note that you already have open projects, at least one other contributor,
and the *implication* that other developers are wanted. Is that genuine or
not? Comments like "open it up to more contributors" raise concerns about
the community approach here.

That said, if there are developers interested in lld, I'd very much like to
> hear what design areas they would like documented better.
>

But it's not just design areas they're interested in. They want to hack on
code, and to do that they need to understand the *code*, above and beyond
any design concerns. An essential part of that is doing code reviews and
watching the progress so that they understand how development is
progressing, where things are going, and how to jump in and get involved.

Questions like: How would X be handled by an in-memory based linker?  or
> How does the Atom model handle a cpu with feature X, etc.   Getting me to
> document  those design points will help everyone come up to speed and see
> how their needs fit into the lld model, and ensure lld can support
> (eventually) everyone's linking needs.
>

Yes, absolutely. But these aren't mutually exclusive, they are
complementary. =]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120611/24ad609f/attachment.html>