[cfe-dev] extending ClangTool libASTUnit saving and loading

mobi phil mobi at mobiphil.com
Fri Dec 19 20:06:57 PST 2014


put back CC the list, maybe Richard's answer is interesting for somebody
else...

First, the C++ standard library: If you're using recent libc++, you already
> have module maps for it. If you're using libstdc++, I can't help -- I don't
> have such a module map.
>
> Then the C standard library: I have a module map for glibc that I've been
> using for a year or so, and it's needed very little maintenance. One
> additional tweak needed is to move around some of the contents of
> <assert.h>, because it does things which are hostile to modules. I can
> provide you with a patch if you like.
>

hm.. it seems that the threshold is a bit high. I thought producing modules
would work straightforward with any library or library headers. So I need
to patch the full glibc source or just the headers? Well I did read the
article on "http://clang.llvm.org/docs/Modules.html" but my understanding
of modules is still poor, so will need some time to catch-up, but the patch
may be useful at a certain moment, thanks.


> If you're using a recent Mac OS system, you already have module maps for
> your C standard library, but ... they're not compatible with C++. With a
> little manual effort, you could probably get them working.
>

I develop on a ubuntu



>
>
>> now back to "clang -c Sema.ast" ... isn't it fair to intuitively assume
>>>> that it would treat the ast as a precompiled unit with all the ingredients
>>>> (headers) instead of PCH? In best case clang should recognize what kind of
>>>> ast is behind and behave accordingly?
>>>>
>>>
>>> That's a reasonable assumption, but the question is, what code should we
>>> generate when you compile from an AST file like this? Right now, we
>>> generate code for all the externally-visible definitions in the AST file
>>> (and we do the same thing whether the AST file is a preamble, a PCH, or a
>>> module). That's liable to change in the future (in particular, we may
>>> introduce a mechanism to say "do not generate definitions for an inline
>>> function in a module in every user of the module; instead, generate the
>>> code once from the module itself").
>>>
>>
>> well, for me the answer is simple and my reasoning is based on a probably
>> over-simplified assumption and that is maybe I am intrigued. (Do I miss
>> sthg?) So for me for instance
>>
>> clang -c $SEMA_DIR/Sema.cpp -o Sema.o $BUNCH_OF_COMPILER_FLAGS
>> #should be equivalent with the pair of commands
>> clang -emit-ast $SEMA_DIR/Sema.cpp -o Sema.ast $BUNCH_OF_COMPILER_FLAGS
>> #and
>> clang -c Sema.ast -o Sema.o $MAYBE_SOME_EXTRA_FLAGS
>>
>>
>>
>> rgrds,
>> mobi phil
>>
>> being mobile, but including technology
>> http://mobiphil.com
>>
>


-- 
rgrds,
mobi phil

being mobile, but including technology
http://mobiphil.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141220/d7af6d2b/attachment.html>


More information about the cfe-dev mailing list