Ralf Hemmecke <[EMAIL PROTECTED]> writes:
[...]
| So each time I modify a file which is called configure.ac.pamphlet or
| Makefile.am.pamphlet, I should run "build-setup.sh". What if I forget
| that? There should be at least a warning telling me that I should run
| "build-setup.sh".
Ralf --
A
C Y <[EMAIL PROTECTED]> writes:
[...]
| I prefer the idea of "one file per concept",
strongly agreed.
For me, the issue here is that of organizing information for human
comprehension. I simply cannot handle gigantic file, no matter how
powerful my computers are.
-- Gaby
_
--- Ralf Hemmecke <[EMAIL PROTECTED]> wrote:
> But what I think is important is, not just to write HUGE files that
> nobody can manage anymore, but to add a bit of structure to it.
> Nowadays we could write a whole book into just one latex file. But
> I bet, most people structure that via severa
On Thursday, August 03, 2006 2:34 PM Ralf Hemmecke wrote:
> ...
> And the "book" idea is good, but it is not perfect. You have
> already said that you want to write books for different people,
> look from a different perspective onto the same data. So wouldn't
> it be nice to have all these data
On 08/03/2006 04:10 PM, root wrote:
I guess the literate idea even says that it does not matter how a file
is called. It is most important that you write a paper from which you
can generate all the code (even different files from one pamphlet
source). That sounds nice, but in some sense I find
> I guess the literate idea even says that it does not matter how a file
> is called. It is most important that you write a paper from which you
> can generate all the code (even different files from one pamphlet
> source). That sounds nice, but in some sense I find that very difficult
> to mai
Ralf Hemmecke <[EMAIL PROTECTED]> writes:
| Hi Gaby,
|
| > | If for the bootstrapping file configure.ac.pamplet (that should be
| > | enough?) we restrict to just several code chunks of the form
| > | | <<*>>=
| > | code here
| > | @
| > | ...
| > | <<*>>=
| > | other code
| > | @
| > | | All the
Makefile.am does not need to be linear. In fact, Makefile.am is
sufficiently high-level enough that if and when we get there, we will
see that Tim already did the job. We just need to re-structure
Makefile.pamphlet first. You won't have to write Makefile.am,
because you will write Makefile.pamp
Hi Gaby,
| If for the bootstrapping file configure.ac.pamplet (that should be
| enough?) we restrict to just several code chunks of the form
|
| <<*>>=
| code here
| @
| ...
| <<*>>=
| other code
| @
|
| All these <<*>> chunks are linearly concatenated by notangle to give
| the final output.
Ralf Hemmecke <[EMAIL PROTECTED]> writes:
| > | If I understand the question, you are asking how we can have only
| > literate | program files in Axiom at the get go and still not depend
| > on noweb. The | simple answer is, we can't. Actually, we can if we
| > don't insist that literate files mu
Ralf Hemmecke <[EMAIL PROTECTED]> writes:
[...]
| > | I know that "make" checks whether the "Makefile" is as new as it could
| > | be. But does it check whether there is Makefile.in or Makefile.am and
| > | re-generates the Makefile from that???
| > No. Makefile.in usually contains variables tha
| If I understand the question, you are asking how we can have only literate
| program files in Axiom at the get go and still not depend on noweb. The
| simple answer is, we can't.
Actually, we can if we don't insist that literate files must be
pamphlet files or we must use noweb :-)
Well,
Hi Gaby,
I'm sorry if I steal your precious time by my stupid questions...
On 08/02/2006 04:58 PM, Gabriel Dos Reis wrote:
Ralf Hemmecke <[EMAIL PROTECTED]> writes:
[...]
| I don't see a difference between
|
| > (1) modify configure.ac.pamphlet
| > (2) run ./build-setup.sh
|
| an
Cliff Yapp <[EMAIL PROTECTED]> writes:
[...]
| > | In a way, it's the same problem Tim faced with Axiom being needed to
| > | build Axiom. The only way out was (and still is) to have some files in
| > | lisp present, to teach lisp to read and understand BOOT and SPAD. Same
| > | deal here.
| >
Ralf Hemmecke <[EMAIL PROTECTED]> writes:
[...]
| I don't see a difference between
|
| > (1) modify configure.ac.pamphlet
| > (2) run ./build-setup.sh
|
| and my suggested
|
| modify configure.ac.pamphlet
| make configure
"make" means that there is a Makefile that is use
Hi Gaby,
| 3) For developers who want to work on the build process and need to
| change configure.ac.pamphlet. Here
|
| ./configure
| make configure
That is too circular and too complicated. It is a good recipe for subtle
bugs. We don't want to be too clever at that level.
| au
On Tuesday 01 August 2006 11:02 pm, you wrote:
> Actually, we can if we don't insist that literate files must be
> pamphlet files or we must use noweb :-)
OK, point...
> | As long as configure.ac.pamphlet is written and maintained in
> | the .pamphlet file I don't see a problem with special cas
Ralf Hemmecke <[EMAIL PROTECTED]> writes:
| >Based on the feedback I got, I implemented the Autoconf-based
| > configuration stuff as a pamphlet file (see below).
|
| I think, Bill's suggestion is the right one. We have a pure ./configure
| file that is distributed with the Axiom sources and
Ralf Hemmecke <[EMAIL PROTECTED]> writes:
| Hi Gaby,
|
| your working times are remarkable. Aren't you in Texas? ;-)
Yes. One nice thing about having a baby who is growing a tooth is
that you for sure will be awaken some nights :-)
| I have seen that there are now also ChangeLog files under
|
Based on the feedback I got, I implemented the Autoconf-based
configuration stuff as a pamphlet file (see below).
I think, Bill's suggestion is the right one. We have a pure ./configure
file that is distributed with the Axiom sources and a configure.ac.pamphlet.
We have two ways to compile A
Hi Gaby,
your working times are remarkable. Aren't you in Texas? ;-)
I have seen that there are now also ChangeLog files under axiom/src/doc
and axiom/src/boot. Is it common to have *not* just one top-level
ChangeLog? Now I am getting confused of where I should enter my
changelog stuff.
Ral
Ralf Hemmecke <[EMAIL PROTECTED]> writes:
| Does that help you? I am running debian sarge.
| I don't see a ./config file in that directory.
Ralf --
Based on the feedback I got, I implemented the Autoconf-based
configuration stuff as a pamphlet file (see below). At the moment,
the only thing
Tim,
On Wednesday, August 02, 2006 12:11 AM you asked:
>
> Do you have an up-to-date set of sources from which you can
> build the windows image? Are they someplace I can get at them?
>
Up-to-date? No, only the originals in the arch axiom--windows--1
branch and the same sources in darcs - both
Bill,
Do you have an up-to-date set of sources from which you can build the
windows image? Are they someplace I can get at them?
t
___
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/mailman/listinfo/axiom-developer
Gaby,
On Tuesday, August 01, 2006 11:02 PM you wrote:
> ...
> I'm not a windows developer, so I'll leave the windows stuff
> to others (hi Bill).
>
The windows build uses MSYS/MingGW so there is not much
difference from the usual linux build process. All of the
standard developer tools work in
"Page, Bill" <[EMAIL PROTECTED]> writes:
| On Tuesday, August 01, 2006 10:12 PM Cliff Yapp wrote:
| > ...
| > I thought it would end up like this:
| >
| > 1) Have configure.ac and configure.ac.pamphlet both present
| > in the top level directory. configure.ac.pamphlet is where
| > editing is d
On Tuesday, August 01, 2006 10:12 PM Cliff Yapp wrote:
> ...
> I thought it would end up like this:
>
> 1) Have configure.ac and configure.ac.pamphlet both present
> in the top level directory. configure.ac.pamphlet is where
> editing is done, and when a commit is made (for this one file)
> a c
Cliff Yapp <[EMAIL PROTECTED]> writes:
| On Tuesday 01 August 2006 6:49 pm, Gabriel Dos Reis wrote:
|
| > | Most open source installations ship a pre-generated ./configure
| > | file and I think Axiom should be no different.
| >
| > Yes, that is what we will do. That configure is generated by Au
On Tuesday 01 August 2006 6:49 pm, Gabriel Dos Reis wrote:
> | Most open source installations ship a pre-generated ./configure
> | file and I think Axiom should be no different.
>
> Yes, that is what we will do. That configure is generated by Autoconf
> based on configure.ac. Autoconf does not e
"Page, Bill" <[EMAIL PROTECTED]> writes:
[...]
| >For that I've converted the current configure file to
| > configure.ac (which Autoconf will use to regenerate configure).
| > The main motivation here is factor out many platforms variability
| > issues and dump them on Autoconf -- who already
Ralf Hemmecke <[EMAIL PROTECTED]> writes:
| Does that help you? I am running debian sarge.
| I don't see a ./config file in that directory.
Thanks for the feedback. Let me, first, merge your changes to silver,
then commit mine to build-improvements. I'll send you a ping for
testing.
Are you c
Gaby,
On Tuesday, August 01, 2006 3:50 PM you wrote:
>
> Instead of fiddling at infinitum with the new build machinery on
> my local disk. I decided to trim it down to something "simple" to
> request feedback about some aspects of the work.
>
> The core goal is to move Axiom's build system
Does that help you? I am running debian sarge.
I don't see a ./config file in that directory.
Ralf
woodpecker:~/OTHER/Axiom/Silver/build-improvements>uname -a
Linux woodpecker 2.6.11-rc4 #3 Thu Feb 23 14:31:45 CET 2006 i686 GNU/Linux
woodpecker:~/OTHER/Axiom/Silver/build-improvements>autoconf co
33 matches
Mail list logo
