[Liboil] Orc-0.4.0

[Jeff Squyres]

On Jun 1, 2009, at 6:18 PM, David Schleef wrote:

> > - can OMPI's configure call your configure (preferably at an m4  
> level,
> > not directly invoking ./orc/configure)
>
> Presumably AC_CONFIG_SUBDIRS() would work, but I don't know details.
>

Nope, it won't.  Our configure/build system is fairly complex --  
there's subtle (and, frankly, uninteresting) reasons why it won't.   
But that's ok -- see below.

> > - can we name-shift all of orc's symbols to ompi_orc (just to be  
> sure we
> > don't conflict with someone's already-installed orc)
>
> I don't know of a good way to do that.
>

We've used two different ways, but both are kinda icky:

- have a top-level "rename.h" file that does "#define real_name  
fake_name" for every public symbol and ensure to include that file  
everywhere.

- declare/define all public symbols with a RENAME() macro that will  
change the name (e.g., by putting a prefix on it).

As mentioned above, both of these are kinda icky, but they do give  
independence from any installed version of the embedded software.   
More importantly, it allows us to QA/qualify with the specific  
embedded version of the software (vs. whatever version happens to be  
installed on the system), and have one less dependency on what the  
user already has installed on their system.

That being said, we can always work around such issues -- like I said  
in my first mail, I figured at least ask if such features were on the  
drawing boards.

> > One other question: I assume that Orc emits code that is supported  
> by
> > the GCC assembler.  Does it support any other compiler suites?   
> (mainly
> > asking about x86_64 Linux compilers, like Intel, PGI, etc.)
>
> I've been cleaning up code in anticipation of a migration to Intel
> assembler syntax.  Gas handles it just fine, so there's no reason
> not to use it.  I'm considering adding a flag for which syntax to
> generate, but the features/complexity ratio there is pretty low.
>
> Of course, runtime code generation doesn't require an assembler.
>


Fair enough.  I'll have to go read the docs more thoroughly, think  
about how it would map to our code base, and see if Orc is a good fit  
for us.

Thanks!

-- 
Jeff Squyres
Cisco Systems