Ralf Hemmecke <[EMAIL PROTECTED]> writes:
| Dear Gaby,
|
| On 08/03/2008 03:58 PM, Gabriel Dos Reis wrote:
| > Ralf Hemmecke <[EMAIL PROTECTED]> writes:
| >
| > | Dear Gaby,
| > |
| > | since I wanted to add a new directory "aldor" to the build process, I
| > | thought that adding it to the SUBDIRS variable (i.e to
| > | axiom_src_subdirs in configure.ac) would be enough, but that didn't
| > | work.
| > |
| > | Now looking a bit deeper, I find that I also must add something like an
| > | all-aldor target in src/Makefile.in and add 'all-aldor' to
| > | axiom_src_all in configure.ac.
| > |
| > | Isn't that a bit too much, i.e., redundant?
| > |
| > | Shouln't src/Makefile.in be totally simple, i.e. just distribute the
| > | work to the Makefiles in its subdirectories?
| > |
| > | Interestingly (and confusingly), the all-... targets in that file do
| > | not directly correspond to subdirectories. :-(
| > |
| > | Sometime back you said you wanted to include automake into the build
| > | process. Do you still have some plans for it?
| > |
| > | Ralf
| >
| > In OpenAxiom, nobody modifies src/Makefile.in directly. Rather,
| > configure.ac.pamphlet is modified and then ./build-setup.sh is run (in
| > the toplevel directory) to automatically update what needs to be
| > updated.
| >
| > In you add a directory to src/ then you have to say when you want it
| > to be built -- for example, lisp/ is built before interp/ and algebra/.
| > Note also that nobody is expected to directly modify SUBDIRS, because
| > it gets its value as computed by `configure' -- the configure-time
| > value of `axiom_src_subdirs'.
|
| Look at
|
http://fricas.svn.sourceforge.net/viewvc/fricas/branches/aldor-interface/src/Makefile.in?view=markup
|
| I had to add...
|
| all-aldor: all-axiomsys all-algebra
| cd aldor && ${MAKE}
|
| No?
Assuming one always to build all-aldor.
| I understand that there is need to add dependencies, but to add also
|
| cd aldor && ${MAKE}
|
| should not be needed, but rather be generic.
Probably.
|
| > In OpenAxiom, nobody modifies src/Makefile.in directly.
|
| Then tell me how you want do it without modifying src/Makefile.in.
You modify the corresponding pamphlet file, and you run
./build-setup.sh in the toplevel directory. If the target is
built conditionally, then it is preferred to set it in the
configure.ac.pamphlet -- see the various places when axiom_src_all is
computed.
| But perhaps the Aldor interface is uninteresting for OpenAxiom.
Interesting logic.
|
| And yes, I've modified, configure.ac. I've already learned about the
| autoconf way of building things.
In OpenAxiom, configure.ac is a generated file -- so nobody modifies
it directly.
| > Just putting the directory in axiom_src_subdirs is not enough: There
| > is not reason to believe that it is going to build `at the right time'
| > if no further information is provided (especially with parallel builds).
|
| That could be done by giving dependencies between the directories.
Exactly -- and that is what is done.
| Or must in Axiom some directory be partially built, then build another and
| then build the rest of the first? What a design?
Something like that. For example interp/ is visited twice, once
for interpsys and once for AXIOMsys. I believe hyper/ is visited
twice too.
|
| > axiom_src_all is the list of src/ `toplevel' targets that say what need to
| > be built for a given platform -- for example, on Windows, not
| > everything is built. It is a mistake to modify it directly. Rather
| > its modification should be done through `configure' -- for example, I
| > suspect you want to test whether user really wanted to have the aldor
| > interface built, or whether the aldor compiler is there, etc.
|
| That's what I did in configure.ac.
|
http://fricas.svn.sourceforge.net/viewvc/fricas/branches/aldor-interface/configure.ac?view=markup
|
| > The all- targets are logical, not necessarily in one-to-one
| > correspondance with directory names.
|
| I think, making them correspond to directories would perhaps simplify
| the build process. Perhaps some directories should be split. What do you
| think?
So far the issue never came up, and I do not know how much of
`genericity' is gained (and how that is helpful in this specific case)
since the dependency has to be set up manually and not all the rules
the same, compared to the resulting complexity from moving away from
logical build to organizing around directory names.
-- Gaby
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
open-axiom-devel mailing list
open-axiom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
