Re: [PATCH v8 32/41] environment: add set_index_file()
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- Jul 29, 2016, 18:35 UTC
- Message-ID
- <CACsJy8C=d-PsfEuRw_XoE3=E6+2_a7Pai1oFv0pEuQsqXwsWwA@mail.gmail.com>
- In-Reply-To
- <CAP8UFD3pZedUPWTj1A8q0zBGhR5ATL3CXOCxHf1_4Fuo+Uu4UQ@mail.gmail.com>
On Fri, Jul 29, 2016 at 8:23 PM, Christian Couder <christian.couder@gmail.com> wrote:
Show 22 quoted lines
> On Fri, Jul 29, 2016 at 5:34 PM, Duy Nguyen <pclouds@gmail.com> wrote: >> >> Yeah. If the libification movement is going strong, we can start >> converting and at some point should be able to define >> NO_THE_INDEX_COMPATIBILITY_MACROS globally (and avoid the_index along >> the way) >> >> Without that, there is a risk. I looked at 'nm apply.o | grep ' [Uu] >> '' and I don't see any external functions that would potentially >> access the index, except ll_merge. Again there's a good chance I may >> have missed something. >> >>> So it looks like it is a very big and different project to make the >>> current libified code be explicit about which index it is using. >>> And by the way perhaps this other project should just remove the >>> "the_index" global altogether. >> >> This is probably the way to go. But it's the boring sort of work that >> nobody wants to do :( > > Do you mean that it might be a source of micro-projects for the next > GSoC or Outreachy? ;-)
No that's what I meant by boring. This is not something to interest GSoC candidates, and while it looks simple, sometimes it needs a good understanding of git overall, and it's definitely not small enough for a micro project. It's very similar to i18n-izing the code base. Luckily Vasco Almeida came out of nowhere and did (still do) that. There may be another Vasco somewhere ;-)
-- Duy