Fork of maxima for make it more embeddable.

Happy New Year!

I understand risks of patches.

I made mirror of original maxima repository on github and branch that
has name 'quicklisp':

https://github.com/filonenko-mikhail/orig-maxima/commit/f0a68af97aa318d7a554c30f32369754244edfd7

1. I removed archive directory. Quicklisp repository does not need
history of project.
2. I moved maxima.asd to root maxima directory. It is simplier to
setup paths, when project file is in the project root.
3. I replaced *.in files, which require configure step, with
asdf*.lisp files, which contain path searching mechanism using asdf
api.
4. I removed setup of output binary files, because asdf2 does not
require this feature.

This version passed all "non-share" tests. Loading some share maxima
libraries is not working now, because it uses mk-defsystem.

Additionally to previous changes in quicklisp branch I ask following changes:

refactor (string= autoconf:win32 "true) to #+-win32;
replace all mk-defsystems with asdf systems. asdf is almost fully
compatible with defsystem.
  remove setup of output binary files;
  move setup paths from several functions into one;
  refactor functions, which work with filenames, to use pathnames
instead of strings;
  remove embedded f2cl and use it from quicklisp;
  remove sloop;

But may be there are no critical mass of people, who want to use quicklisp?

2011/12/30 Rupert Swarbrick <rswarbrick at gmail.com>:
> Leo Butler <l_butler at users.sourceforge.net> writes:
>> Rupert Swarbrick <rswarbrick at gmail.com> writes:
>>> Michael Filonenko <filonenko.mikhail at gmail.com> writes:
>>>> Goal of fork to provide maxima from quicklisp. Maxima big project and I
>>>> need community opinion about fork. I am ready to merge my changes with
>>>> main repo. Only non-mathematical parts were changed by me.
>>>
>>> Hmm. Well, a public github fork is a pretty awful way to develop
>>> features on changing code unless that code is also in github. How are
>>> you going to incorporate changes to core maxima into your fork without
>>> rewriting history?
>>
>> @Rupert: I am not really certain of your meaning here. Git can
>> accomodate multiple upstream repositories. So long as he has forked
>> things correctly, he can pull in updates from sourceforge, and merge
>> these onto his development branch which is on github. This work can be
>> merged into the sourceforge repository without re-writing anyone's
>> history -- that is the nice thing about rebasing.
>
> Yes, but github forks are public repositories, so if you rebase you
> screw up the repository of anyone trying to follow you...
>
> Rupert
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>



-- 
With best regards, Michael Filonenko