[Openais] call for roadmap features for future releases

Fabio M. Di Nitto fdinitto at redhat.com
Sun Jun 21 10:24:01 PDT 2009


On Sun, 2009-06-21 at 08:43 -0700, Steven Dake wrote:
> captured your other comments, but curious about following so I
> understand what you mean:
> 
> On Sun, 2009-06-21 at 07:31 +0200, Fabio M. Di Nitto wrote:
> > On Sat, 2009-06-20 at 11:51 -0700, Steven Dake wrote:
> [snip]
> 
> > - integration of .spec files and debian/ into upstream to allow people
> > to easily build rpm/deb.
> > 
> could you be more specific here, I'm not certain I totally understand
> the requirement.  Do you mean to ship spec files with the tarball for
> those archs?

Basically yes. I am experimenting with cluster at the moment to have:

make srpm and make rpm targets.

There is a cluster.spec.in that generates cluster.spec at configure time
by substituting a few vars inside (only a few are really required).

For debian, it's a bit more complex because it requires a debian/
directory with a bunch of files but I have enough knowledge to bootstrap
it.

The idea is to involve all major distribution packagers to maintain
those bits and be able to release binary packages a lot faster, if not
the same day as the tarball release.

The final tarball would contain both .spec.in and debian/ directories.

As I am absolutely sure you remember, we very often do the rpm build
test before any snapshot release. Having those targets in the tree, will
help to do that too.

The only cons is that both spec files and debian/ dirs need to be
updated properly during the development cycle between each release.

Tho.. truth told, I already do in my local test clusters... doing it
upstream is a matter of an svn commit extra (read it has it's low
overhead for me).

> > - switch the code to use OS based features rather than the BUILD_FOO
> > version we have now (it's ugly and it should die).
> > 
> 
> could you be more specific here?  We have two different things:
> COROSYNC_PLATFORM (in C/H files)
> BUILD_PLATFORM (in makefiles)

> 
> Do you suggest to remove both of those?  Seems like an interesting goal,
> but I'm not certain how it would work out in practice.

Yes both should go away in favour of feature based detection. Detecting
the OS is wrong and it doesn't scale in time.

>   For example,
> solaris doesn't support constructor execution via dlopen.  We could get
> rid of COROSYNC_SOLARIS for this if we had a specific test case in
> configure.ac (like C code to run during configure that verified if the
> platform worked or not).  Seems like alot of special test cases we have
> to add to configure.ac to set the proper config.h variables.  Is there
> some other option?

We didn't exploit all the tests we can do in configure.ac.

For some special situations we will have to write our test cases but the
scalability here arrives in time, when we will need to either build on
other OS'es or an OS changes feature set.

For example, if at some point in time Solaris will execute constructs at
dlopen, the feature will be detected and used automatically. Without us
changing one single line of code while as it is now, we need to patch a
lot of files around to make it working.

Writing a test case for this specific situation is far from complex. See
for example what we do to check cc_supports_flag. We pass an extremely
small piece of code there to build.
For dlopen test, just make main return 1 and the construct return 0,
execute the test and check for result. If 0 it means dlopen construct
are supported. So after all it's a matter of writing very very small
tests and we have the support for macros to do that.

Fabio




More information about the Openais mailing list