omniidl(1)
π omniidl β the omniORB idl compiler (section 1 of the General Commands Manual) π
okay bestie, sit down, hydrate, because today we're learning about omniidl β the omniORB IDL compiler β and honestly? she's iconic. β¨
β¨ NAME β¨
omniidl β omniORB idl compiler. that's it, that's the name, she's straightforward like that π
β¨ SYNOPSIS β¨
omniidl [options] -b<back-end> [back-end options] file
π¦ DESCRIPTION π¦
so omniidl is the omniORB IDL compiler front end. and here's the tea: if you don't specify a back-end, she just checks your input IDL file for validity and produces, like, nothing. zero output. she's just there to vibe-check your IDL and tell you if it's valid. π
usually though you DO specify a language mapping back-end, because that's the whole point β that's how you get stubs and skeletons in whatever target language you're mapping to. that's the main character behavior right there. π
and before your files even get parsed by the compiler, they go through the C preprocessor first. so that's a whole thing that happens upstream of everything else, just so you know.
πΈ COMMON OPTIONS πΈ
these are the ones everybody gets, no matter which back-end you pick:
-b<backend>β run the specified back-end. like,-bcxxfor C++,-bpythonfor Python. pick your fighter π-D<name>=<value>β define<name>for the C preprocessor.-U<name>β undefine<name>for the C preprocessor.-I<dir>β add<dir>to the C preprocessor search path.-Eβ only run the C preprocessor, sending its output to stdout. no parsing, no back-end, just preprocessing, periodt.-Y<cmd>β use<cmd>as the preprocessor instead of the default one.-Nβ do not run the C preprocessor at all.-Wp<arg>β send<arg>to the C preprocessor.-Wb<arg>β send<arg>to the back-end.-nfβ don't warn about unresolved forward declarations. (she's chill about it π«Ά)-kβ keep comments after declarations, to be used by some back-ends.-Kβ keep comments before declarations, to be used by some back-ends.-C<dir>β change directory to<dir>before writing output files.-dβ dump the parsed IDL then exit, without running a back-end.-p<dir>β use<dir>as a path to find omniidl back-ends.-Vβ print version information then exit.-uβ print usage information.-vβ verbose: trace compilation stages. she's telling you EVERYTHING bestie π£οΈ
π₯ C++ BACK-END π₯
choose her with -bcxx. but heads up: the C++ back-end is only available when you have omniORB for C++ installed. no omniORB for C++, no C++ back-end, sorry babe π
she produces two output files:
- a header
- a stub/skeleton file
and by default they're named by appending the suffixes .hh and SK.cc to the base name of the input IDL file. cute, right?
now β if you specify the -Wba option, a third file gets generated too, with default suffix DynSK.cc, and it contains code for TypeCode and Any. β¨
π C++ BACK-END OPTIONS π
-Wbh=<suffix>β use<suffix>instead of.hh-Wbs=<suffix>β use<suffix>instead ofSK.cc-Wbd=<suffix>β use<suffix>instead ofDynSK.cc. and listen: if you specify the same suffix for both-Wbsand-Wbd, then you get a single skeleton file containing all the definitions output. one file, all the definitions, slay.-Wbaβ generate definitions forTypeCodeandAny.-Wbinlineβ output stubs for#includedIDL files in line with the main file.-Wbtpβ generate tie implementation skeletons.-Wbtfβ generate flattened tie implementation skeletons.-Wbsplice-modulesβ splice together multiply-opened modules into one.-Wbexampleβ generate example implementation code.-WbBOAβ generate BOA compatible skeletons.-Wbkeep_inc_pathβ preserve IDL#includepaths in generated#includedirectives.-Wbuse_quotesβ use quotes in#includedirectives (e.g."foo"rather than<foo>).
π PYTHON BACK-END π
choose her with -bpython. the Python back-end produces Python packages according to the standard IDL to Python mapping, to be used with omniORBpy. and yeah, same energy as before: the Python back-end is only available when you have omniORBpy installed. π
she generates Python package directories named after the modules declared in IDL, as required by the IDL to Python mapping. and she also creates separate stub files that get imported by the packages. multitasking queen. π
π PYTHON BACK-END OPTIONS π
-Wbinlineβ output stubs for#includedIDL files in line with the main file.-Wbglobal=<name>β use<name>as the name for the global IDL scope (default_GlobalIDL).-Wbpackage=<name>β put both Python modules and stub files in package<name>.-Wbmodules=<name>β put Python modules in package<name>-Wbstubs=<name>β put stub files in package<name>
π SEE ALSO π
go read the omniORB or omniORBpy manual for the full details of omniidl, iykyk. π
π«Ά AUTHOR π«Ά
Duncan Grisby. king behavior, honestly. π
real talk bestie: this page is from AT&T Laboratories, Cambridge, dated 2001, and it documents omniidl(1) from the General Commands Manual. π β¨ go forth and compile, you gorgeous thing πΈπ¦
π¦ where this page comes from
- debian bookworm: omniidl 4.2.5+ds1-1.1+b1 Β· LGPL-2.0-or-later
- debian trixie: omniidl 4.3.3+ds1-1 Β· LGPL-2.0-or-later
- epel 9: omniORB-devel 4.3.0-6.el9 Β· LGPLv2+
- fedora 43: omniORB-devel 4.3.3-7.fc43 Β· LGPL-2.0-or-later
- fedora 43: omniORB-devel 4.3.3-7.fc43 Β· LGPL-2.0-or-later
- fedora 44: omniORB-devel 4.3.4-2.fc44 Β· LGPL-2.0-or-later
- fedora 44: omniORB-devel 4.3.4-2.fc44 Β· LGPL-2.0-or-later
- ubuntu jammy: omniidl 4.2.5-1 Β· LGPL-2.0-or-later
- ubuntu noble: omniidl 4.3.2+ds1-1.1build2 Β· LGPL-2.0-or-later
- ubuntu questing: omniidl 4.3.3+ds1-1
- ubuntu resolute: omniidl 4.3.3+ds1-1build1 Β· LGPL-2.0-or-later
- ubuntu stonking: omniidl 4.3.4+ds1-1build1 Β· LGPL-2.0-or-later
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms