Opened 14 years ago
Closed 7 years ago
#1337 closed defect (fixed)
Handle Susan problems when building without OMC
Reported by: | adrpo | Owned by: | adrpo |
---|---|---|---|
Priority: | high | Milestone: | Bootstrapping |
Component: | Template Code Generation | Version: | |
Keywords: | Cc: | adrpo, ppriv, sjoelund.se, wbraun |
Description
When you have a clean directory (no OMC build) and you change types in the type view
you cannot build OMC anymore as SimCode.mo doesn't agree with SimCodeC.mo and SimCodeCSharp.mo.
We should be able to build Susan separately so we can *ALWAYS* build then generated files
when there are changes in the templates and the type view and we don't have an OMC available.
Change History (3)
comment:1 Changed 14 years ago by sjoelund.se
comment:2 Changed 9 years ago by dietmarw
- Cc changed from adrpo, adrpo, ppriv, sjoelund.se, wbraun to adrpo, ppriv, sjoelund.se, wbraun
- Milestone set to Future
comment:3 Changed 7 years ago by sjoelund.se
- Milestone changed from Future to Bootstrapping
- Resolution set to fixed
- Status changed from new to closed
- Summary changed from Build the Susan executable separately from omc to resolve problems with building to Handle Susan problems when building without OMC
This was fixed when we bootstrapped OMC
The problem is also that we need to store generated files (SimCodeC.mo, etc) in svn. If we build a minimal Susan, we can build it before omc.exe instead of running make omc twice (once on the checked-in sources to generate omc, then create the templates).
The problem with generating this executable is that Compiler/runtime depends on Absyn.h. We would need to split Compiler/runtime into parts that are OMC-dependent (actually, mostly just dynload.c, simulationresult.cpp).
According to SusanTest.mos only Print, RTOpts and System is required.