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
Hi,
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 to GNU Autotools which
have become quite standard now, in t
34 matches
Mail list logo
