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