Comments (9)
Definitely a bug.
However, source_file_line is not what is needed. What is needed at build and generation times are the name of the pkg-config project that provides the file as well as the include that should be used. The metadata that could be thrown away happily is actually source_file_line
from orogen.
Ok, pkg-config -- fine.
But the file to be included to use the type in question -- is the file where the type itself is declared. Which is the where source_file_line
points to?
from orogen.
Yes, but not really. First, it is made relative based on the CFLAGS of the pkg-config in orogen_include. Moreover, it is resolved to the toplevel include (the file priovided to #import_types_from), not the exact include, as for instance the header defining Eigen::Matrix cannot be included directly while Eigen/Core can.
from orogen.
Hm. Have to think about this. Rationale: gccxml is called to "preprocess" the headers into one big file. There, some logic does the mapping which include-file should be used... And gccxml is bound to go.
from orogen.
- what do you mean with relative based on the CFLAGS of the pkg-config in orogen_include?
- jeah, its converted from an absolute path to some relative path -- So that the compiler can look it up again during parsing of the template-derived code?
- Example-Time:
Eigen::Vector3d
has an opaque and is used in a header. The generated tlb containssource_file_line = /usr/include/eigen3/Eigen/src/Core/Matrix.h:373
. A manually createdmain.cpp
like
#include "/usr/include/eigen3/Eigen/src/Core/Matrix.h"
int main(int argc, char *argv[])
{
Eigen::Vector3d test;
return 0;
}
compiles just fine... Where is my misunderstanding?
The clang-derived importer could provide everything which can be extracted from the cpp -- and orogen can only do worse.
from orogen.
Because you do not KNOW whether it can be or not. The typical case is C++ standard headers, they are split in tons of small headers that are NOT meant to be included. Only the standard headers (like ) are. And there's really nothing clang can help you with there.
The only headers you KNOW can be included directly are the ones that have been explicitly given to orogen. Matrix.h ? Not part of eigen's documentation ... This is not a header you are meant to include directly. That it works is just by chance, not by design.
As for the CFLAGS: the problem is to generate code that can be relocated / generated on one machine and compiled on another. The resolution basically takes the absolute path and uses the package's pkg-config -I options to find out what is the most likely #include<> line and the corresponding CMake code.
from orogen.
Ok, got the point. But clang can help us here, like so for example. For me this feels more sane than orogen calling gcc(xml) again just to resolve this include-chain.
As for the CFLAGS: the problem is to generate code that can be relocated / generated on one machine and compiled on another. The resolution basically takes the absolute path and uses the package's pkg-config -I options to find out what is the most likely #include<> line and the corresponding CMake code
chuckle Did someone ever try to move the generated code from one machine to another? I very much doubt that this will reliably (read: reliably) work. So much interpreted magic eating and spitting options and files here and there... Installing stuff and not installing stuff, environment here and there... Using the just the full path in the generated code would prevent the later compiler from accidentally looking up the wrong header.
So what about the importer setting a metadata "full_include_path", and orogen then churning on this full path to create the "orogen_include" with a hopefully correct relative path given some pkg-config flags?
from orogen.
Ok, got the point. But clang can help us here, like so for example. For me this feels more sane than orogen calling gcc(xml) again just to resolve this include-chain
Streamlining the process is of course a good thing. Now, it does not change the fact that it needs to be done one way or another...
You don't need to sell clang to me ... I am in love with it already (and will happily sign the death sentence to the gccxml importer).
So what about the importer setting a metadata "full_include_path", and orogen then churning on this full path to create the "orogen_include" with a hopefully correct relative path given some pkg-config flags?
This is exactly what currently happens, with the importer setting source_file_line and orogen "massaging" it to the orogen_include
As to the portability: if the code was written manually, this is exactly the approach one would take: add the dependency on the pkg-config file, include the header from the pkg-config-resolved library. Might not be perfect, but - in general - following the way everyone does it in practice sounds like a pretty good idea to me.
from orogen.
You don't need to sell clang to me ... I am in love with it already (and will happily sign the death sentence to the gccxml importer).
Yes. Sometimes I need more control over my moment of inertia... ;-)
from orogen.
Related Issues (20)
- Problem with base/samples/frame/Frame in orogen HOT 12
- Get task names from an orogen project HOT 14
- default extensions are enabled twice in imported projects
- kernel_require.rb:55:in `require': cannot load such file -- orogen (LoadError) HOT 2
- Error if ro_ptr is passed as argument of operation HOT 2
- orogen cannot handle "C style" typedef'ed structs correctly HOT 18
- Orogen does not include inherited ports when port_driven
- orogen: Merge toolchain-2.7 and master branches for the 2.8 release HOT 5
- Overwritten TypeInfo for standard types? HOT 1
- metaruby dependency not found HOT 1
- Multiple metadata entries in properties HOT 3
- generated main does not compile on OSX HOT 7
- orogen generate invalid typlib files (includes are resolved wrongly) HOT 5
- Updated doc for new plugin system naming HOT 1
- Create base class for all plugins and document it HOT 1
- oroconf extract error HOT 2
- default task de-constructor is not virtual HOT 1
- Orogen Internal error HOT 6
- orogen missing catkin build tool dep HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from orogen.