[llvm-dev] Email list just for front end developers?

Sat May 20 11:39:00 PDT 2017

Hi,

2017-05-11 20:03 GMT-07:00 Perry E. Metzger via llvm-dev <
llvm-dev at lists.llvm.org>:

> On Thu, 11 May 2017 20:14:11 +1000 Dean Michael Berris via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > FWIW, I think the "modern" way of doing any of this is with any one
> > of the following services (that don't need to be owned/maintained
> > by the LLVM Foundation):
> >
> >   - Stack Overflow (maybe if it gets large enough, get a "vertical"
> > for just LLVM usage)
>
> Unfortunately, stack overflow works best for questions where there
> are a lot of people who know the answers and people are willing
> to actively log in day after day to answer questions. It works great
> for "how do I use SQL to do something" but less well for small
> niches. The LLVM questions I've seen posed there seem to usually have
> zero or one answers rather than the large number common things get.
>
> >   - Reddit (if there isn't an /r/llvm yet, that might be a good
> > "community" place for less llvm-dev worthy material)
>
> Maybe. I like mailing lists because you don't have to poll them.
> Having to log in constantly to a service to see if there is
> discussion waiting is a bit of a pain. (I have to admit I've never
> been much of a reddit fan in general.)
>
> >   - Slack (if there isn't one yet, maybe an llvm-users slack
> > instance for more persistent discussions)
>
> There is an IRC channel already, though my experience with it as a
> help mechanism has been mixed as it seems more geared towards the
> middle and back end.

I think you should persevere a bit more on the IRC side. Keep in mind that
it is more active during the US timeframe.
Most questions I don't see answered are about specific of the clang
frontend internals, but not about LLVM. I totally expect questions on the
IR Builder to be answered. Some of the questions about "what IR to generate
to do X" are easily answered by "Have you tried clang?" (I usually followup
with a link to godbolt...).

> And even if people decided this was a good idea,
> without the LLVM foundation documenting it somewhere, no one will
> find it.
>

You're mistaken on the role of the LLVM foundation: it is mostly
administrative.

If you feel something is not documented correctly, please submit a patch.
The LLVM community as a whole is responsible for this.
(you can checkout llvm.org webpages, they are in the SVN repository, and
commit access to LLVM gives you commit access to the website as well).

We may benefit from a more dedicated section of http://llvm.org/docs for
frontend developers, feel free to take the lead on developing such a
section and starting with documentation and examples.
Note I'm not really fond of wiki because 1) it diverges from the way we
handle documentation, 2) it does not integrate with our review flow (commit
mailing list) and 3) it is harder to keep up to date (example in the doc
can come with test that can be part of `make check` so that everyone
maintains it when an API changes).

> All that said, I might be wrong and these might be the better path.

"better" or "best" are hard to predict and evaluate. Also it is usually in
my opinion a matter of tradeoff: you may win on some aspect but lose on
others. So different people who would weight these aspects differently may
end up on a different conclusion regarding the "better" end results.

About having a mailing list specific for frontend developer, the risk I see
is the same as http://lists.llvm.org/pipermail/cfe-users/ : there may not
be many people there to answer questions. Especially as we're talking about
"unstable" LLVM APIs: the people with all the knowledge are supposed to on
llvm-dev.
I also think that asking the kind of question you mentioned: "what is the
API to create a global string?" are appropriate to ask on llvm-dev, and
pinging the thread after a few days should help getting an answer
(sometimes I may see such question but I'm busy and figure that someone
else will answer, if there is a ping after a week I'm more likely to spend
some time answering it).

Overall I also agree with Sean that what seems missing in the tutorial is
an overview of how to navigate the LLVM codebase to know where to look to
find the right API for the job.

-- 
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170520/a8f7b547/attachment-0001.html>