Re: [SEToolkit-developer] Crosscompiling for unified packaging
Brought to you by:
dmichelsen
|
From: Alex K. <ale...@gm...> - 2007-04-02 09:15:17
|
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 |