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, -bcxx for C++, -bpython for 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 of SK.cc
  • -Wbd=<suffix> β€” use <suffix> instead of DynSK.cc. and listen: if you specify the same suffix for both -Wbs and -Wbd, then you get a single skeleton file containing all the definitions output. one file, all the definitions, slay.
  • -Wba β€” generate definitions for TypeCode and Any.
  • -Wbinline β€” output stubs for #included IDL 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 #include paths in generated #include directives.
  • -Wbuse_quotes β€” use quotes in #include directives (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 #included IDL 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 πŸŒΈπŸ¦‹