[Rock-dev] gccxml -> clang

Discussion:

Matthias Goldhoorn

2014-06-26 09:01:38 UTC

I just tried to get into the gccxml and clang stuff.

Unfortunately even this is horrible regarding the Debian support.
The standard Debian stable points to llvm-3.0, the example i want to
start with was
http://clang.llvm.org/docs/RAVFrontendAction.html, which is based on
llvm-3.5.

I'm using debian testing, therefore i already had installed version 3.4
which contains the needed files (e.G. clang/AST/ASTConsumer.h), but no
cmake support, compiling with the helper llvm-config-3.4 results in
unresolved symbols.
The llvm-3.5 packages does not have the needed header again... *warghs*.

Don't know if this is the right way to go now, of course we can compile
clang with autoproj, but is this the way to go.
I not checked ubuntu so far, but on debian it is starting to annoy me
before i really started...

Best,
Matthias
--
Dipl.-Inf. Matthias Goldhoorn
Space and Underwater Robotic

Universit?t Bremen
FB 3 - Mathematik und Informatik
AG Robotik
Robert-Hooke-Stra?e 1
28359 Bremen, Germany

Zentrale: +49 421 178 45-6611

Besuchsadresse der Nebengesch?ftstelle:
Robert-Hooke-Stra?e 5
28359 Bremen, Germany

Tel.: +49 421 178 45-4193
Empfang: +49 421 178 45-6600
Fax: +49 421 178 45-4150
E-Mail: matthias.goldhoorn at informatik.uni-bremen.de

Weitere Informationen: http://www.informatik.uni-bremen.de/robotik

-------------- n?chster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140626/cef2692b/attachment.htm

Sylvain Joyeux

2014-06-26 09:23:13 UTC

Permalink

On Thu, Jun 26, 2014 at 11:01 AM, Matthias Goldhoorn <

Post by Matthias Goldhoorn
Unfortunately even this is horrible regarding the Debian support.
The standard Debian stable points to llvm-3.0, the example i want to start
with was
http://clang.llvm.org/docs/RAVFrontendAction.html, which is based on
llvm-3.5.

We don't support debian stable anyways. I am not even sure Rock builds on
debian stable.

Post by Matthias Goldhoorn
I'm using debian testing, therefore i already had installed version 3.4
which contains the needed files (e.G. clang/AST/ASTConsumer.h), but no
cmake support, compiling with the helper llvm-config-3.4 results in
unresolved symbols.

The llvm-3.5 packages does not have the needed header again... *warghs*.
Big deal, we'll have to write a cmake macro (or even look for one on the
web) in order to get a full C++ compiler as a library. That sounds like a
fair deal to me. Moreover, clang-3.5-dev does include the header you've
listed.

Post by Matthias Goldhoorn
Don't know if this is the right way to go now, of course we can compile
clang with autoproj, but is this the way to go.

Definitely not.

Getting annoyed because cmake integration does not "just work" when you are
looking at something as big as clang is ... a bit asking for too much.

Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140626/b3bcff28/attachment-0001.htm

Sylvain Joyeux

2014-06-26 09:32:19 UTC

Permalink

Post by Sylvain Joyeux
Getting annoyed because cmake integration does not "just work" when you
are looking at something as big as clang is ... a bit asking for too much.

Let me put it another way: if you write a well-working typelib plugin that
loads C++ using clang but is using hardcoded paths to build, I'll happily
take care of the CMake code.

Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140626/9e5b28fa/attachment.htm

Martin Zenzes

2014-06-26 11:34:51 UTC

Permalink

Post by Sylvain Joyeux
Getting annoyed because cmake integration does not "just work"
when you are looking at something as big as clang is ... a bit
asking for too much.
Let me put it another way: if you write a well-working typelib plugin
that loads C++ using clang but is using hardcoded paths to build, I'll
happily take care of the CMake code.

writing the cmake-stuff is easier than understanding their AST
matchers... ;-) i'm sure the debian maintainer has interest in this as
well...

Post by Sylvain Joyeux
Sylvain
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

--
M.Sc. Martin Zenzes
Space Robotics

Hauptgesch?ftsstelle Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 5
28359 Bremen, Germany

Phone: +49 (0) 421 178 45 - 6658
Fax: +49 (0) 421 178 45 - 4150
E-Mail: martin.zenzes at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra?e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140626/0a41dd63/attachment.htm

Sylvain Joyeux

2014-06-26 11:46:22 UTC

Permalink

writing the cmake-stuff is easier than understanding their AST matchers...
;-) i'm sure the debian maintainer has interest in this as well...

My point, exactly ;-)

Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140626/47e5c5b1/attachment.htm

Matthias Goldhoorn

2014-06-26 12:03:03 UTC

Permalink

I hate using packages if they start to annoy me so early ;).
Nevertheless i took a breath and restarted.

Its hard-here because clang consists of a lot of libs that (as usual)
needs to be arranged in the right order...
...i continue...

Post by Martin Zenzes
writing the cmake-stuff is easier than understanding their AST
matchers... ;-) i'm sure the debian maintainer has interest in
this as well...
My point, exactly ;-)
Sylvain
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

--
Dipl.-Inf. Matthias Goldhoorn
Space and Underwater Robotic

Universit?t Bremen
FB 3 - Mathematik und Informatik
AG Robotik
Robert-Hooke-Stra?e 1
28359 Bremen, Germany

Zentrale: +49 421 178 45-6611

Besuchsadresse der Nebengesch?ftstelle:
Robert-Hooke-Stra?e 5
28359 Bremen, Germany

Tel.: +49 421 178 45-4193
Empfang: +49 421 178 45-6600
Fax: +49 421 178 45-4150
E-Mail: matthias.goldhoorn at informatik.uni-bremen.de

Weitere Informationen: http://www.informatik.uni-bremen.de/robotik

-------------- n?chster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140626/a70f9f6e/attachment.htm

Matthias Goldhoorn

2014-06-30 08:01:32 UTC

Permalink

I had now a working dev-setup (with manual compiled clang), the
external-compilign-support IS a pain in the -------,

Nevertheless what i want to to is to understand how the type-creation is
currently done in orogen/typelib with gccxml.

So far i understood
1. orogen calls the gccxml and forwards it to the typelib
2. typelib creates the structure and tlb's
3. finished

what i don't understand, the gccxml output is only kind of
"preprocessor" output.
How are the padding/sizes/alignments are created or calculated, where is
this part?
I only found this in orogen lib/orogen/gen/typekit.rb:1406. But i have
no clue how the typeinfos are gathered.

Best,
Matthias

Post by Matthias Goldhoorn
I hate using packages if they start to annoy me so early ;).
Nevertheless i took a breath and restarted.
Its hard-here because clang consists of a lot of libs that (as usual)
needs to be arranged in the right order...
...i continue...

--
Dipl.-Inf. Matthias Goldhoorn
Space and Underwater Robotic
Universit?t Bremen
FB 3 - Mathematik und Informatik
AG Robotik
Robert-Hooke-Stra?e 1
28359 Bremen, Germany
Zentrale: +49 421 178 45-6611
Robert-Hooke-Stra?e 5
28359 Bremen, Germany
Tel.: +49 421 178 45-4193
Empfang: +49 421 178 45-6600
Fax: +49 421 178 45-4150
E-Mail:matthias.goldhoorn at informatik.uni-bremen.de
Weitere Informationen:http://www.informatik.uni-bremen.de/robotik
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

Sylvain Joyeux

2014-06-30 15:25:05 UTC

Permalink

On Mon, Jun 30, 2014 at 10:01 AM, Matthias Goldhoorn <

Post by Matthias Goldhoorn
1. orogen calls the gccxml and forwards it to the typelib

Nope. orogen calls typelib to import a C/C++ file using Registry#import and
typelib does the importing using gccxml. From the p.o.v. of orogen, gccxml
does not exist.

Post by Matthias Goldhoorn
2. typelib creates the structure and tlb's

Correct. The gccxml output is parsed by typelib's gccxml importer to create
a typelib registry. This is what is returned to orogen.

what i don't understand, the gccxml output is only kind of "preprocessor"

Post by Matthias Goldhoorn
output.

The gccxml output contains the whole information. The gccxml importer
extracts only what typelib will need (throws away all the method/function
information). This is in big part why the import is so damn slow, a gccxml
output can be very easily multi-MB of XML while we need maybe 1% of it.

Post by Matthias Goldhoorn
How are the padding/sizes/alignments are created or calculated, where is
this part?
I only found this in orogen lib/orogen/gen/typekit.rb:1406. But i have no
clue how the typeinfos are gathered.

The padding / alignment / sizes should NOT be calculated, but provided by
the compiler. I was doing it once upon a time, but that's really really
fragile to do right.

By the way, with clang the whole process should be done within typelib in
C++. No need to pass through Ruby.

Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140630/31ea56bb/attachment.htm