Re: Building prog first
* On Sun, Mar 21, 2010 at 10:27 AM, Ralf Wildenhues wrote: noinst_PROGRAMS = unimain unimain_SOURCES = unimain.c unidata.tab.c: unimain$(EXEEXT) /usr/share/unicode/UnicodeData.txt ./unimain$(EXEEXT) $ $@ BTW, execution of built programs like this makes your package unsuitable for cross-compilation. Just so you're aware of that. Assuming unidata.tab.c is a C-code table containing the information from UnicodeData.txt, I think it could be better to generate it by some shell code (maybe inside the Makefile.am, saving a tool) or to use perl (for the price of adding perl to the build dependencies) or, if UnicodeData rarely changes, add unidata.tab.c to the package and have some `maintainer only' helper target to build it (with unidata.tab.c as distributed source file). People who don't care about unidata.tab.c can build the package even without UnicodeData.txt (if this makes any sense, I don't know what this is for of course :)) oki, Steffen
Re: Building prog first
Steffen Dettmer wrote: * On Sun, Mar 21, 2010 at 10:27 AM, Ralf Wildenhues wrote: noinst_PROGRAMS = unimain unimain_SOURCES = unimain.c unidata.tab.c: unimain$(EXEEXT) /usr/share/unicode/UnicodeData.txt ./unimain$(EXEEXT) $ $@ BTW, execution of built programs like this makes your package unsuitable for cross-compilation. Just so you're aware of that. Assuming unidata.tab.c is a C-code table containing the information from UnicodeData.txt, I think it could be better to generate it by some shell code (maybe inside the Makefile.am, saving a tool) or to use perl (for the price of adding perl to the build dependencies) or, if UnicodeData rarely changes, add unidata.tab.c to the package and have some `maintainer only' helper target to build it (with unidata.tab.c as distributed source file). People who don't care about unidata.tab.c can build the package even without UnicodeData.txt (if this makes any sense, I don't know what this is for of course :)) I though of perl, but (A), i don't like slow tools, (B), unidata.tab.c is 5.6MBytes and 450k lines long, (C), i find making build-programs in C much more concise than scripting and i can debug it in ddd/gdb. The size of unidata.tab.c precludes distributing it. I could do more work on compacting it, but i have already done that to a degree.
Re: Building prog first
2010/3/22 Russell Shaw rjs...@netspace.net.au: Steffen Dettmer wrote: * On Sun, Mar 21, 2010 at 10:27 AM, Ralf Wildenhues wrote: BTW, execution of built programs like this makes your package unsuitable for cross-compilation. Just so you're aware of that. Not true. automake does not have explicit support for building programs with the host compiler when cross-compiling, but I have done this successfully in the past when I needed precisely to build a program on the host when cross compiling, using binutils's BFD_CC_FOR_BUILD macro. It's a pity some version of this macro isn't in autoconf, or even autoconf-archive; I shall do the latter. This illustrates a weirdness of autotools: poor support for installing interpreted languages, and also conversely for build-time compiled programs. I though of perl, but (A), i don't like slow tools, Purlease... (B), unidata.tab.c is 5.6MBytes and 450k lines long, and? (C), i find making build-programs in C much more concise than scripting and i can debug it in ddd/gdb. This is interesting, as it doesn't match mine or commonly-reported experience (translating my build-time programs from C to Perl made them shorter, easier to read and fix, and no slower to run, although I wasn't doing more than grepping 15k lines of C and writing some of it back out again). -- http://rrt.sc3d.org
Re: Building prog first
If searching is the problem how does the indices not fix the problem? What about using a info browser to search through the manual?
Re: Building prog first
On 3/22/2010 4:34 PM, Reuben Thomas wrote: What about using a info browser to search through the manual? I often do that. The trouble is that often what I want to know has to be deduced from the manual, which is natural enough, because the manual tends to be structured according to the structure of the program it documents, rather than of the problems the user is trying to solve. By using web searches I can often find people asking and answering precisely the problem I'm trying to solve. Reuben, you've just hit upon one of the two most significant problems with Javadoc and the like (including doxygen, man pages, and info pages): 1. You have to already know the API to know where to look for help on the API because the documentation is structured according to the API, rather than according to the top 100 use cases. 2. Most people don't add more than method header comments to their source code, which means there's often no concept documentation, just method documentation, which is useless to people trying to learn the API. This isn't always true. Some projects try hard to add concept docs too, but just very few by comparison. Just a comment. John
Automake Installation Error
I have configured/make/make install on autoconf with no problems.
I have run automake's configure with no problems.
However, when I run make while trying to install automake I get the error:
-bash-3.1$ make
CDPATH=${ZSH_VERSION+.}: cd .
perllibdir=/home/wdrozd/cmake/automake-1.11.1/lib:./lib
/home/wdrozd/cmake/automake-1.11.1/aclocal --acdir=m4 -I m4
/bin/sh: /home/wdrozd/cmake/automake-1.11.1/aclocal: No such file or
directory
make: *** [aclocal.m4] Error 127
Can someone please help?
Thanks,
Bill
Re: Building prog first
On 3/22/10 6:50 PM, John Calcote wrote: Reuben, you've just hit upon one of the two most significant problems with Javadoc and the like (including doxygen, man pages, and info pages): Agreed -- which is why I think it would be wonderful if there was strong Autotools support for literate programming. Unfortunately, my m4-fu is not strong enough to figure out the appropriate macros to discover ctangle, cweave, etc. smime.p7s Description: S/MIME Cryptographic Signature
