setoolkit-developer — Developer discussions about changes to come

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

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

Re: [SEToolkit-developer] Crosscompiling for unified packaging

[Alex K. <ale...@gm...>]

On 01/04/07, Dagobert Michelsen <da...@ba...> wrote:
> >> PS: Autoconf works great. I am rebuilding the packaging process and
> >> used autoconf for sparc, sparcv9, i386 and amd64
> >>     without problems.
> >
> > 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.

> > One thing which did occur is that if we really wanted to the pieces
> > are all there to allow a single platform to cross compile everything
> > (I haven't done cross compilers for getting on for 10 years...)
>
> This is (at least for SS11 to my knowledge) currently impossible. See
>   http://forum.java.sun.com/thread.jspa?threadID=5104192&tstart=75
>   http://forum.java.sun.com/thread.jspa?
> threadID=5072312&messageID=9264958
> With gcc this should be possible however, but I prefer sticking to SS11)
>

That fine by me!

> 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'.

> 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.

> 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).

> One really last thing: I would like to convert the documentation
> of the langauge in doc/* to an up-to-date metaformat to produce ascii/
> html/pdf/man/...
> As I have never began a new documentation project, do you have any
> experiences with, say, DocBook, doxygen or another recommendation?
>

pod's about the only thing I've any experience which is even vaguely
recent, but I'm not sure I'd want to use that for anything more than
man pages.

-- 
Alex Kiernan

[Setoolkit-developer] Crosscompiling for unified packaging

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

Hi Alex,

Am 01.04.2007 um 18:11 schrieb Alex Kiernan:
> On 01/04/07, Dagobert Michelsen <da...@ba...> wrote:
>> I added another mailing list
>>   set...@li...
>> We should discuss things on the list to have an archive of stuff we
>> talked about and to let others participate.
>>
>
> Yup - sounds good to me.

I cc:'ed to the list.

>> PS: Autoconf works great. I am rebuilding the packaging process and
>> used autoconf for sparc, sparcv9, i386 and amd64
>>     without problems.
>
> 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.

> One thing which did occur is that if we really wanted to the pieces
> are all there to allow a single platform to cross compile everything
> (I haven't done cross compilers for getting on for 10 years...)

This is (at least for SS11 to my knowledge) currently impossible. See
   http://forum.java.sun.com/thread.jspa?threadID=5104192&tstart=75
   http://forum.java.sun.com/thread.jspa? 
threadID=5072312&messageID=9264958
With gcc this should be possible however, but I prefer sticking to SS11)

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.

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?
Should we attempt to port/investigate/document how the examples
match to D-scripts?

One really last thing: I would like to convert the documentation
of the langauge in doc/* to an up-to-date metaformat to produce ascii/ 
html/pdf/man/...
As I have never began a new documentation project, do you have any
experiences with, say, DocBook, doxygen or another recommendation?


Best regards

   -- Dagobert