Re: [SEToolkit-developer] Crosscompiling for unified packaging

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

Hi Alex,

your post seems to come from you directly instead of the mailing list. I cited
all for archive purpose. Have you just replied to my last mail or do I need to
tweak something in Mailman?

Von "Alex Kiernan" <ale...@gm...> (Mon, 2 Apr 2007 16:32:08 +0100):
> On 02/04/07, Dagobert Michelsen <da...@ba...> wrote:
> > 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.
> >
> 
> On a cross compile, it'd pick up the cross-compile setting from the
> AC_... macro - for that I'd just set it to success (on the assumption
> that if you're building using a cross you really ought to know what
> you're doing).

Ok.

> > > > 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.
>
> This makes some sense - so assume we drop out examples, we'd remove:
> 
> dist_examples_DATA
> dist_examplesdata_DATA
> dist_netexamples_DATA
> nobase_dist_pkgdata_DATA
> 
> from configure.ac and list them as EXTRA_DIST so they get collected
> when you do `make dist' (in fact we can just list the directories).
> 
> A simple make install would get you all the pieces you need to run
> orcallator (or indeed any of the other examples), but none of the
> examples themselves.
> 
> I quite like that approach - it greatly simplifies things.
> 
> [I just spotted I've not done the right thing with se_defines - I'll
> relocate that to $(sysconfdir).]

Ok.

> > > > 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?
> 
> I'd be inclined to split orcallator from setoolkit and orca (which
> actually is what we've done - we install an setoolkit and orcallator
> package on machines, and then an orca package elsewhere).

Should orcallator go to orca or stay with setoolkit?
Should it be necessary to install orca just for the orcallator?
Maybe we should put the updated libs in orca and continue
to include a current version of the orcallator.
The footprint of orcallator is very small and as most people
will install SE for orcallator it would be convenient too.


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