Re: [SEToolkit-developer] Crosscompiling for unified packaging

[Dagobert M. <da...@ba...>]

Hi Alex,

Von "Alex Kiernan" <ale...@gm...> (Mon, 2 Apr 2007 10:15:15 +0100):
> On 01/04/07, Dagobert Michelsen <da...@ba...> wrote:
> > > Excellent - it was well worth committing it; your comments managed to
> > > trigger the idea of how to make it build the "right" version for a
> > > particular platform - I'll commit it shortly (I seem to have some
> > > network problems at the moment).
> >
> > This sounds difficult to me. It must produce the correct version for
> > the compiling host regardless of the compiler (SS11 or gcc) and it
> > must be possible to easily overwrite this. I used setting CC to
> > "/opt/SUNWspro/bin/cc -xarch=generic64" which would certainly collide
> > with setting made at a different place in configure.
> 
> My thought was to write an autoconf test which did:
> 
> #ifdef _LP64
> exit(0);
> #else
> exit(1)
> #endif
> 
> which will pick a 64 bit compilation option, no matter how specified,
> then compare the result with what `isainfo -b' says. But you do then
> need another autoconf option which says don't do this magic - on
> balance, perhaps the warning is the better option. Also once you need
> to do `isainfo -b', the option of cross-compiling goes out of the
> window.

Not necessarily. I'll expect a warning if the built binary is not suitable
for the running kernel. A test with kvm_open might be more meaningful.
On crosscompilation the binary won't execute and would issue a warning too.

> > One more thing: you moved the examples to share/se. I would like to
> > keep the directory structure of the package in "RICHPse-form" as
> > it has always been. The share/se-part is hardcoded. Do you see
> > a possibility of customizing this via configure (maybe datarootdir?)
> > to build an package with the customary directory structure?
> > For a package in blastwave-form the current format is ok.
> 
> Probably if you override pkgdatadir - we'd need then to substitute the
> directories into the various .se files. pkgdatadir doesn't look to be
> settable by an option to configure, so maybe we'd need to add
> something like `--enable-RICHPse-layout'.

I find this too heavy-weight for a problem which may go away sometime.
Some more ideas:
- keep examples/ out of autoconf and stick with pathes hardcoded to examples/
  When people want to have examples they have to install them by hand
  (or maybe a line like 'cp -r examples <dest>' in the Makefile install section)
- packaging picks the examples as always and bundles them in the package.

> > One last thing: do you think anybody is using the SE toolkit apart
> > as the groundwork necessary to run Orca or fire up zoom.se?
> 
> My guess is no.

Another reason against autoinstalling examples.

> > Should we attempt to port/investigate/document how the examples
> > match to D-scripts?
> 
> I'm not sure its worth the effort (but I guess it depends to an extent
> on whether we think anyone is using se for anything more than an
> orcallator base).

This may be a good finger exercise for me (and others?) to become
more familiar with kernel structures and D-Trace.

Here are the next steps I planned:
- put out a RICHPse-package for 3.4.1 on SF. The changelog must be
  adjusted for the fixed issues.
- repackage for blastwave.org
  For this the package-name needs to be configurable. Ad hoc I would say
  autoconf is not needed for this but I haven't checked the code yet.
  The integration of a current version of orca (r529) needs some packages
  which are installed during Orca install. This dependency can be resolved
  easily with dependencies to existing Blastwave-packages. I am unsure
  how to handle this for the RICHPse-style package. Any ideas?
- version 3.5.0 should include autoconf (of course) and a current Orca.
  Further ideas?


Best regards

  -- Dagobert

--
Dagobert Michelsen (Leiter IT)          Baltic Online Computer GmbH
Firmensitz:   Alter Markt 1-2, 24103 Kiel, Telefon: +49 431 54003-0
Geschäftsführer:        Erik Cickovskis, Amtsgericht Kiel, HRB 3756
"Of course computer servers don't need thrust, since they generally
don't go anywhere."  -- Comment in TR on new HP server turbine fans