mkdist.sh and fricas.spkg
Ralf Hemmecke
Remember, I want to make the generation of the fricas.spkg more
automatic. (And for that I have a few tweaks for the
fricas-aldor-interface that can hopefully also go into 1.0.8.)
I guess, that I first have to build fricas. But what are the exact
commands so that mkdist.sh will work.
I have a local build
Ralf
PS: Shouldn't the task of mkdist.sh be better done by makefile rules (so
they would work for an in-place build and an out-of-source/vpath build?
Waldek Hebisch
Before using mkdist.sh you should do full bootstrap. If you
want to create a distribution you should also build graphic
.pht pages (othewise distribution you build will miss
images on HyperDoc pages). mkdist.sh works from top of build
tree. mkdist.sh copies sources and some "compiled" files from
build tree into 'dist' subdirectory of the build tree (the name
is hardcoded into the script). More precisely, mkdist.sh copies
generated Lisp files and .pht pages. For convenience mkdist.sh
may also copy some files which are not in build form SVN
sources -- that is noweb, gcl and help files. For noweb
and gcl one has to specify location of corresponding tarball,
for help files location of apropriate directory.
Proper use depens on what you want to do. One use is to
create release tarball, then we use:
mkdist.sh --copy_lisp --copy_gphts --copy_phts \
--copy_noweb=.... --copy_help=....
Actually, currently --copy_phts implies --copy_gphts
but this may change. For current distribution I did not
use the option to bundle gcl.
Another possibility is when for testing I want to re-build
FriCAS, but to save time I do not want to re-compile algebra
and re-build .pht pages. In such case --copy_noweb=... and
--copy_help=.... are of little use, so
mkdist.sh --copy_lisp --copy_phts
is enough.
Concerning .spkg, do you want to create .spkg from svn
snapshot? If you use releases as base for .spkg then
all mkdis.sh can do is already done.
Concerning making the process more automatic -- for me mkdist.sh
was enough. The point is that when creating release tarball
there are several steps that does not automate well. Namely,
making sure that X is available for building graphics, locating
extra files, checking test results.
> PS: Shouldn't the task of mkdist.sh be better done by makefile rules
> (so
> they would work for an in-place build and an out-of-source/vpath
> build?
>
mkdist.sh performs recursive copy which really works only for out
of source build.
Main criterion for mkdist.sh was simplicity and robustness. The
point is that I use mkdist.sh to make releases, so I want it to run
really reliably in controlled enviroment. Using make would mean
more complexity and conseqenty more effort to get it right. And
I am not sure if effect would be wort the effort.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
> Before using mkdist.sh you should do full bootstrap.
That is clear.
> If you want to create a distribution you should also build graphic
> .pht pages (othewise distribution you build will miss
> images on HyperDoc pages).
Ehm, since I'm on Linux with a running X that should be the default. No?
Or do I have to give some extra 'configure' switches.
> Concerning .spkg, do you want to create .spkg from svn
> snapshot?
Certainly not. I think, I stick with the releases directory in the SVN
repository. I think the version number of the .spkg should agree with
the version number of FriCAS. It's better to maintain only proper fricas
releases. Just creating the .spkg should be more automatic.
> If you use releases as base for .spkg then
> all mkdis.sh can do is already done.
I probably don't understand this one. Do you mean that I simply can extract
http://sourceforge.net/projects/fricas/files/fricas/1.0.7/fricas-1.0.7-full.tar.bz2/download
to the src directory of my spkg directory? That would be wonderful. Much
easier to create an .spkg.
So I would only have to generate libaxiom.al for a second
fricasaldor-1.0.7.spkg? That would really ease my scripts.
> Concerning making the process more automatic -- for me mkdist.sh
> was enough. The point is that when creating release tarball
> there are several steps that does not automate well. Namely,
> making sure that X is available for building graphics, locating
> extra files, checking test results.
Well, if I can start from the tarball from sf.net that should be
sufficient for Sage. FriCAS is build sufficiently often so that there is
currently no need for a package generated from the SVN sources.
Thanks for the hints. I hope I can produce something tonight and test it.
Ralf
Waldek Hebisch
>
> Thank you for your instructions.
>
> > Before using mkdist.sh you should do full bootstrap.
>
> That is clear.
>
> > If you want to create a distribution you should also build graphic
> > .pht pages (othewise distribution you build will miss
> > images on HyperDoc pages).
>
> Ehm, since I'm on Linux with a running X that should be the default. No?
> Or do I have to give some extra 'configure' switches.
>
See the first part of INSTALL.
> > Concerning .spkg, do you want to create .spkg from svn
> > snapshot?
>
> Certainly not. I think, I stick with the releases directory in the SVN
> repository. I think the version number of the .spkg should agree with
> the version number of FriCAS. It's better to maintain only proper fricas
> releases. Just creating the .spkg should be more automatic.
>
> > If you use releases as base for .spkg then
> > all mkdis.sh can do is already done.
>
> I probably don't understand this one. Do you mean that I simply can extract
>
> http://sourceforge.net/projects/fricas/files/fricas/1.0.7/fricas-1.0.7-full.tar.bz2/download
>
> to the src directory of my spkg directory? That would be wonderful. Much
> easier to create an .spkg.
Yes. I the past the spkg was sometimes patched compared to release
tarball, but the patch was tiny.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
> create release tarball, then we use:
>
> mkdist.sh --copy_lisp --copy_gphts --copy_phts \
> --copy_noweb=.... --copy_help=....
I understand, that I should have
--copy_noweb=/path/to/noweb-2.10a.tgz
but I don't quite understand what I should give after
--copy_help=
Can I simply take the stuff that comes in src/share/spadhelp in
http://sourceforge.net/projects/fricas/files/fricas/1.0.7/fricas-1.0.7-full.tar.bz2/download
?
In my builddir the src/share/spadhelp only contains Makefile and stamp
(after a full build from SVN trunk@r672).
Why isn't there anything anyway? Does that mean my compilation from the
sources is incomplete?
Ralf
Waldek Hebisch
>
> > Proper use depens on what you want to do. One use is to
> > create release tarball, then we use:
> >
> > mkdist.sh --copy_lisp --copy_gphts --copy_phts \
> > --copy_noweb=.... --copy_help=....
>
> I understand, that I should have
>
> --copy_noweb=/path/to/noweb-2.10a.tgz
>
> but I don't quite understand what I should give after
>
> --copy_help=
>
> Can I simply take the stuff that comes in src/share/spadhelp in
> http://sourceforge.net/projects/fricas/files/fricas/1.0.7/fricas-1.0.7-full.tar.bz2/download
> ?
>
Yes.
> In my builddir the src/share/spadhelp only contains Makefile and stamp
> (after a full build from SVN trunk@r672).
>
> Why isn't there anything anyway? Does that mean my compilation from the
> sources is incomplete?
>
Currently the only thing done in this Makefile is to copy
command.list to target directory.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
hemmecke
>
> > --copy_help=
>
> > Can I simply take the stuff that comes in src/share/spadhelp in
> > ?
>
> Yes.
That is somehow unsatisfactory. I'd like to create the distribution
from an svn checkout.
I can wget the noweb sources (as described in the INSTALL file), but I
have no idea how to generate
the spadhelp/*.help files.
If these *.help files are in some way necessary for fricas to run
properly, then why aren't they
made by default from an svn checkout?
Can/should I perhaps just ignore those *.help files for the spkg
generation, i.e. just include the lisp
and the graphics files?
Actually the same question arises for the ghpts target. Cannot
configure check whether an X server
is running and thus switch on/off the gphts generation in src/paste?
How do I have to call the *top-leve* make to generate the gpths files?
I think that calling
make
cd src/paste
make gphts
cd ../..
make
is unsatisfactory.
Ralf
Waldek Hebisch
>
> > > but I don't quite understand what I should give after
> >
> > > --copy_help=
> >
> > > Can I simply take the stuff that comes in src/share/spadhelp in
> > >http://sourceforge.net/projects/fricas/files/fricas/1.0.7/fricas-1.0....
> >
> > Yes.
>
> That is somehow unsatisfactory. I'd like to create the distribution
> from an svn checkout.
> I can wget the noweb sources (as described in the INSTALL file), but I
> have no idea how to generate
> the spadhelp/*.help files.
>
> If these *.help files are in some way necessary for fricas to run
> properly, then why aren't they
> made by default from an svn checkout?
>
*.help are a textual version of (some of) Hyperdoc pages. They
are shown by )help command -- if you do not have them )help
shows nothing. ATM the process of creating help files is
not automated -- few files in the distribution tarball are
taken from NAG cdrom, the rest was created by Tim Daly.
> Can/should I perhaps just ignore those *.help files for the spkg
> generation, i.e. just include the lisp
> and the graphics files?
The real question is how usefull *.help files are. Given
working HyperDoc I personally found no use of them. But
sometimes (like on "native" Windows) we do not have HyperDoc,
then help may be more useful. Also, preferences vary --
so I decided to ship help file in distribution tarball.
> Actually the same question arises for the ghpts target. Cannot
> configure check whether an X server
> is running and thus switch on/off the gphts generation in src/paste?
Ralf, have you looked at working 'make gphts'? Normal 'make'
can run in the background while user is doing something else.
But 'make gphts' pops images on the screen effectively not
allowing doing any other work. In other words, given current
state of 'make gphts' I do not _want_ it to run by default.
> How do I have to call the *top-leve* make to generate the gpths files?
> I think that calling
>
> make
> cd src/paste
> make gphts
> cd ../..
> make
>
> is unsatisfactory.
>
We can put equivalent rule in top-level Makfile.in if that makes
a difference.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
>> properly, then why aren't they made by default from an svn
>> checkout?
> *.help are a textual version of (some of) Hyperdoc pages. They are
> shown by )help command -- if you do not have them )help shows
> nothing.
Aha! I've never used )help till now. ;-)
> ATM the process of creating help files is not automated -- few files
> in the distribution tarball are taken from NAG cdrom, the rest was
> created by Tim Daly.
Anybody can give a hint how the could/should be generated from the SVN
sources. If it's not too hard, I'll add a patch. Or can we perhaps just
include those .help files and the necessary installation code into the
FriCAS archive until we have some code that generates them?
Opinions?
> The real question is how usefull *.help files are. Given working
> HyperDoc I personally found no use of them. But sometimes (like on
> "native" Windows) we do not have HyperDoc, then help may be more
> useful. Also, preferences vary -- so I decided to ship help file in
> distribution tarball.
Right, but I'd like to be able to generate them for the poor
Windows-Users. I just need a hint how this can be done.
>> Actually the same question arises for the ghpts target. Cannot
>> configure check whether an X server is running and thus switch
>> on/off the gphts generation in src/paste?
> Ralf, have you looked at working 'make gphts'?
Oh, yes. Just last night where I compiled not on my local machine. ...
The process was terribly slow. :-(
> Normal 'make' can run in the background while user is doing something
> else. But 'make gphts' pops images on the screen effectively not
> allowing doing any other work. In other words, given current state
> of 'make gphts' I do not _want_ it to run by default.
I understand and agree.
>> How do I have to call the *top-leve* make to generate the gpths
>> files? I think that calling
>>
>> make cd src/paste make gphts cd ../.. make
>>
>> is unsatisfactory.
> We can put equivalent rule in top-level Makfile.in if that makes a
> difference.
Yes, that would make me more happy. Actually the make process should end
with an echo that tells the user how to generate the missing gphts (and
that this will require X and constantly popup and remove graphics windows).
Ralf