Opened 9 years ago
Last modified 9 years ago
#3439 accepted defect
Make 3rdParty includes more homogeneous
| Reported by: | Adrian Pop | Owned by: | Adrian Pop |
|---|---|---|---|
| Priority: | high | Milestone: | Future |
| Component: | Build Environment | Version: | trunk |
| Keywords: | Cc: |
Description
We don't seem to have a clear picture on where to install 3rdParty includes.
We seem to push them into one of these places:
- build/include/omc/c
- build/include/omc/cpp
sometimes in their own directory sometimes not.
We should come up with a clear structure on where to put these includes especially of those libraries that are used by both C and CPP runtimes.
For example for ticket #3426 we need sundials but is not clear where to put the includes. If ones looks into the OpenModelica windows installation we seem to have sundials includes twice inside:
- build/include/omc/cpp
- build/include/omc/cpp/includes
Change History (14)
comment:1 by , 9 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → accepted |
comment:2 by , 9 years ago
comment:3 by , 9 years ago
Seems that both C and CPP runtime uses sundials but I guess only CPP runtime includes the headers. As far as I got it, C runtime uses the libraries directly (only on a flag) for solving some type of systems.
follow-up: 5 comment:4 by , 9 years ago
Yes, the C runtime hides everything behind our own interface.
comment:5 by , 9 years ago
Replying to sjoelund.se:
Yes, the C runtime hides everything behind our own interface.
That's fine but then the question still remains for both includes and libraries, where to put them if they are used by the C and CPP runtimes.
comment:6 by , 9 years ago
The cpp runtime does also not need the sundials headers during simulation.
follow-up: 8 comment:7 by , 9 years ago
Thanks @niklwors for this info. Then I can handle sundials by not copying the headers at all, just use the includes directly from 3rdParty.
comment:8 by , 9 years ago
Replying to adrpo:
Thanks @niklwors for this info. Then I can handle sundials by not copying the headers at all, just use the includes directly from 3rdParty.
Yes, this is ok.
follow-up: 10 comment:9 by , 9 years ago
Seems the generated code for the CPP runtime needs the sundials includes, for example:
FactoryPolicy.h:86:27: error: kinsol/kinsol.h: No such file or directory
comment:10 by , 9 years ago
Replying to adrpo:
Seems the generated code for the CPP runtime needs the sundials includes, for example:
FactoryPolicy.h:86:27: error: kinsol/kinsol.h: No such file or directory
This is a bug, I will fix it.
comment:11 by , 9 years ago
Seems there are also types from sundials includes used:
f:/dev/OpenModelica/build/include/omc/cpp/Solver/CVode/CVode.h:94: error: 'N_Vector' has not been declared f:/dev/OpenModelica/build/include/omc/cpp/Solver/IDA/IDA.h:100: error: 'N_Vector' has not been declared
comment:12 by , 9 years ago
Even inside ModelicaConfig_*.inc.in there is a SUNDIALS_INCLUDE so for now I copied the includes inside lib/omc/c/sundials and adapted the templates to use the SUNDIALS_INCLUDE.
You can play with it and let me know when I should remove the copy of the headers if they are not needed.
follow-up: 14 comment:13 by , 9 years ago
I removed the dependencies for sundials from FactoryPolicy. So normaly the simulation do no longer need the sundials includes
comment:14 by , 9 years ago
Replying to niklwors:
I removed the dependencies for sundials from FactoryPolicy. So normaly the simulation do no longer need the sundials includes
Thanks. I will keep this ticket opened as we still need to decide how to handle 3rdParty libraries a bit more homogeneous.
Only includes that are actually needed by the simulation runtime headers need to be installed into build/include. Which means most of the packages do not need to be there.