Ralf Hemmecke <[EMAIL PROTECTED]> writes: | > | 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. | | Why? I can have a target that is only used if it is mentioned in | @[EMAIL PROTECTED]
I was under the impression that user should be given option to elect to build the Aldor compabitility libs, and that compatibility depends on the Aldor compiler being around. In that case, I think it makes sense to have a configure-time option. If that is true, then whether all-aldor is executed must be computed somehow. The best to collect all Make targets computed at configure time is axiom_src_all for the src/ directory. If you don't agree, could you expand more on your reasons? | > | > 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. | | Aha. Sorry, I forgot that OpenAxiom still uses pamphlets for | Makefile.in. Of course that is better (documented). Not so long time ago, you urged me NOT to remove the build machinery pamphlets that contain the documentations. So, I'm a bit surprised that you did not want to modify the pamphlet, but went straight to the generated Makefile.in and configure.ac. Of course, I still believe that configure.ac can contain the codes AND the documentation -- I already ran into a couple of bugs due to the pamphlets not reflecting the structure of the generated code. No pamphlet != no documentation. and pamphlet != documentation. :-) | > | But perhaps the Aldor interface is uninteresting for OpenAxiom. | | > Interesting logic. | | I think it would have helped if you had reminded me about the use of | pamphlets in OpenAxiom. Sometimes I also get frustrated with the | missing bits of your answers. | | > 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. | | You misunderstood. I don't want to move from a logical build | structure, but rather make the directories reflect that | structure. (Therefore the suggestion of a split of directories.) I believe it requires much more work than cursory glance may suggest and I'm not convinced that the benefits outweight the trouble -- try doing it for interpsys and AXIOMsys to warm up. Until now, the issue never pops up, and I believe the work to install the Make target all-aldor is far less than reorganizing the build structures around directories. I would be inclined to spend my personal time on that instead of the nasty bugs in the system if I could be convinced of the substantial benefits. Or course, that does not mean that I would reject contributed patches. -- 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
