Re: Building prog first
Ralf Wildenhues wrote: Hello Russell, * Russell Shaw wrote on Sun, Mar 21, 2010 at 07:06:00AM CET: I want the "unimain" program built first, then use it to generate unidata.tab.c, which is then compiled and linked into librunicode.la bin_PROGRAMS = unimain unimain_SOURCES = unimain.c unidata.tab.c: /usr/share/unicode/UnicodeData.txt ./unimain $< > $@ Then you need a dependency from unidata.tab.c on unimain: unidata.tab.c: unimain$(EXEEXT) /usr/share/unicode/UnicodeData.txt ./unimain$(EXEEXT) $< > $@ Furthermore, please don't hard-code absolute paths like /usr/share/unicode/UnicodeData.txt in your makefiles. Make them configurable by configure. Maybe your users don't have root rights on their system but have the file installed below their home somewhere? Ok. I did: AC_CHECK_FILE([/usr/share/unicode/UnicodeData.txt], [], []) In "configure", i get: if test "x$ac_cv_file__usr_share_unicode_UnicodeData_txt" = x""yes; then : fi Shouldn't this be: if test "x$ac_cv_file__usr_share_unicode_UnicodeData_txt" = "xyes"; then : fi
Re: Building prog first
Ralf Wildenhues wrote: Hello Russell, * Russell Shaw wrote on Sun, Mar 21, 2010 at 07:06:00AM CET: I want the "unimain" program built first, then use it to generate unidata.tab.c, which is then compiled and linked into librunicode.la bin_PROGRAMS = unimain unimain_SOURCES = unimain.c unidata.tab.c: /usr/share/unicode/UnicodeData.txt ./unimain $< > $@ Then you need a dependency from unidata.tab.c on unimain: unidata.tab.c: unimain$(EXEEXT) /usr/share/unicode/UnicodeData.txt ./unimain$(EXEEXT) $< > $@ Ok, that works thanks:) However, "make install" installs unimain into /usr/local/bin How do i stop this program from being installed? I did: install-exec-hook: rm $(DESTDIR)$(bindir)/unimain$(EXEEXT) This deletes it out of /usr/local/bin after installing it which seems kind of kludgy. Furthermore, please don't hard-code absolute paths like /usr/share/unicode/UnicodeData.txt in your makefiles. Make them configurable by configure. Maybe your users don't have root rights on their system but have the file installed below their home somewhere?
Re: Building prog first
However, "make install" installs unimain into /usr/local/bin Please refer to the manual, it documents how to do that, and more. You can try the chapter `(automake) Fine-grained Distribution Control'.
Re: Building prog first
* Russell Shaw wrote on Sun, Mar 21, 2010 at 09:26:44AM CET: > Ralf Wildenhues wrote: > >* Russell Shaw wrote on Sun, Mar 21, 2010 at 07:06:00AM CET: > >> bin_PROGRAMS = unimain > >> unimain_SOURCES = unimain.c > >unidata.tab.c: unimain$(EXEEXT) /usr/share/unicode/UnicodeData.txt > >./unimain$(EXEEXT) $< > $@ > > Ok, that works thanks:) > > However, "make install" installs unimain into /usr/local/bin > > How do i stop this program from being installed? Use noinst_PROGRAMS instead of bin_PROGRAMS. Be encouraged to read the fine manual. BTW, execution of built programs like this makes your package unsuitable for cross-compilation. Just so you're aware of that. Cheers, Ralf
Re: Building prog first
* Russell Shaw wrote on Sun, Mar 21, 2010 at 08:16:03AM CET: > Ralf Wildenhues wrote: > >Furthermore, please don't hard-code absolute paths like > > /usr/share/unicode/UnicodeData.txt > > > >in your makefiles. Make them configurable by configure. Maybe your > >users don't have root rights on their system but have the file installed > >below their home somewhere? > > Ok. > I did: AC_CHECK_FILE([/usr/share/unicode/UnicodeData.txt], [], []) > > In "configure", i get: > > if test "x$ac_cv_file__usr_share_unicode_UnicodeData_txt" = x""yes; then : > fi > > Shouldn't this be: > > if test "x$ac_cv_file__usr_share_unicode_UnicodeData_txt" = "xyes"; then : > fi First off, no, the two are completely equivalent. This might not be clear from a tutorial about shell quoting, but hey, shell quoting isn't easy. Then, AC_CHECK_FILE doesn't really help your user (and it kills cross compilation, too). If you really want to make this configurable, then provide a switch or command line variables like --enable-unicode-file=location and if that is not given, search for a few known places where this can be. For example, on this system, there exists a file with this name in /usr/share/perl/5.8.8/unicore but I cannot tell you if it has the contents you might expect. Cheers, Ralf
Re: Building prog first
Ralf Wildenhues wrote: * Russell Shaw wrote on Sun, Mar 21, 2010 at 09:26:44AM CET: Ralf Wildenhues wrote: * Russell Shaw wrote on Sun, Mar 21, 2010 at 07:06:00AM CET: bin_PROGRAMS = unimain unimain_SOURCES = unimain.c unidata.tab.c: unimain$(EXEEXT) /usr/share/unicode/UnicodeData.txt ./unimain$(EXEEXT) $< > $@ Ok, that works thanks:) However, "make install" installs unimain into /usr/local/bin How do i stop this program from being installed? Use noinst_PROGRAMS instead of bin_PROGRAMS. Be encouraged to read the fine manual. But it is somewhat big, and i had already searched through the online one a lot first. It is no wonder it takes noobs so long to get productive. BTW, execution of built programs like this makes your package unsuitable for cross-compilation. Just so you're aware of that. Ok. I assume then that you can't build the tool for the host system while the generated files are compiled for the target system?
Re: Building prog first
* Russell Shaw wrote on Sun, Mar 21, 2010 at 11:18:03AM CET: > Ralf Wildenhues wrote: > >Use noinst_PROGRAMS instead of bin_PROGRAMS. Be encouraged to read the > >fine manual. > > But it is somewhat big, and i had already searched through the online > one a lot first. It is no wonder it takes noobs so long to get productive. I'm not sure how to help that. If more documentation makes people less likely to look at it, then what would you suggest in order to improve upon the situation? Is the documentation not structured well enough? Does the "Autotools Introduction" chapter in the Automake manual not help get a basic grasp? I agree that the initial learning steps may not be easy for Automake, but I don't see how to make Automake a lot easier without also ripping out much of the functionality. So turning that knob is fairly unlikely. > >BTW, execution of built programs like this makes your package unsuitable > >for cross-compilation. Just so you're aware of that. > > Ok. I assume then that you can't build the tool for the host system while > the generated files are compiled for the target system? First off, allow me to clarify the nomenclature as it is used in GNU software: - the build system is the one you run configure and 'make all' on, - the host system is the one that the programs which 'make all' normally generates and installs, will run on later, - the target system does not exist. Never. Unless your package happens to be a compiler or linker (or similar). Then, the target system is the one for which your installed compiler/linker will generate code for. With that, your sentence above should have been Ok. I assume then that you can't build the tool for the build system while the generated files are compiled for the host system? Not straight-forwardly, no. Once you've got your basic package working and cross compilation support is the only thing missing, please come back and we'll explain. Cheers, Ralf
Re: Building prog first
Ralf Wildenhues wrote: * Russell Shaw wrote on Sun, Mar 21, 2010 at 11:18:03AM CET: Ralf Wildenhues wrote: Use noinst_PROGRAMS instead of bin_PROGRAMS. Be encouraged to read the fine manual. But it is somewhat big, and i had already searched through the online one a lot first. It is no wonder it takes noobs so long to get productive. I'm not sure how to help that. If more documentation makes people less likely to look at it, then what would you suggest in order to improve upon the situation? Is the documentation not structured well enough? Does the "Autotools Introduction" chapter in the Automake manual not help get a basic grasp? I agree that the initial learning steps may not be easy for Automake, but I don't see how to make Automake a lot easier without also ripping out much of the functionality. So turning that knob is fairly unlikely. Hi, I was limping along for years learning autoconf/make in bits until this tutorial came out Autotools: a practitioner's guide to Autoconf, Automake and Libtool http://www.freesoftwaremagazine.com/books/autotools_a_guide_to_autoconf_automake_libtool I realized a lot of useful things after that. The main thing that makes it easy is that a real project is stepped through with lots of side discussions, and high-level overviews put things in to perspective. I'd really like to have a hard-copy book of that tutorial. After that, i could understand the autoconf manual. I was on dos/windows up to nearly yr2000 or so, so i had to learn unix programming, shell programming, make-file programming, m4, how unix processes work etc, to be able to look in generated Makefiles and "configure" and see from that what errors i was making in configure.ac and automake.am. Learning too many things simultaneously, but i know now. BTW, execution of built programs like this makes your package unsuitable for cross-compilation. Just so you're aware of that. Ok. I assume then that you can't build the tool for the host system while the generated files are compiled for the target system? First off, allow me to clarify the nomenclature as it is used in GNU software: - the build system is the one you run configure and 'make all' on, - the host system is the one that the programs which 'make all' normally generates and installs, will run on later, - the target system does not exist. Never. Unless your package happens to be a compiler or linker (or similar). Then, the target system is the one for which your installed compiler/linker will generate code for. With that, your sentence above should have been Ok. I assume then that you can't build the tool for the build system while the generated files are compiled for the host system? Not straight-forwardly, no. Once you've got your basic package working and cross compilation support is the only thing missing, please come back and we'll explain. Ok. Thanks for the help. -- regards, Russell
Re: Building prog first
Have you tried reading `(automake) Autotools Introduction'? It is part of the automake manual.
Re: Building prog first
Alfred M. Szmidt wrote: Have you tried reading `(automake) Autotools Introduction'? It is part of the automake manual. Hi, I printed out all the autotools manuals and have read every page of them more than once. It was a while ago, so it's easy to forget things. Searching the online manual isn't all successful at times, but i've figured out a fair bit of it now.
Re: Building prog first
On 21 March 2010 11:40, Ralf Wildenhues wrote: > * Russell Shaw wrote on Sun, Mar 21, 2010 at 11:18:03AM CET: >> But it is somewhat big, and i had already searched through the online >> one a lot first. It is no wonder it takes noobs so long to get productive. > > I'm not sure how to help that. If more documentation makes people less > likely to look at it, then what would you suggest in order to improve > upon the situation? Is the documentation not structured well enough? > Does the "Autotools Introduction" chapter in the Automake manual not > help get a basic grasp? > > I agree that the initial learning steps may not be easy for Automake, > but I don't see how to make Automake a lot easier without also ripping > out much of the functionality. So turning that knob is fairly unlikely. I must say that this is a problem for me with many GNU manuals: Emacs's comes to mind as well as most of the autotools' documentation. I struggle to put my finger on what is wrong: one of the nice things about GNU manuals compared to many other pieces of documentation is that they are on the whole comprehensive, and everything is beautifully and clearly explained, with few missing bits, in properly written sentences. And yet, when trying to learn new things even with packages I'm quite familiar with (any of the above, for example), I often end up feeling that I'm in a twisty maze of documentation pages, all alike. I chase references, I try searching, I go round in circles... Usually, the best way out, I find, is to do a web search. I have a couple of suspicions: 1. This is not a fault especially of GNU documentation; rather, GNU documentation is one of the few places in free and open source software where one finds properly written manuals. Proprietary manuals seem to suffer from the same problems (I think of similar feelings I get from perusing Microsoft Office help, for example). 2. I suspect the problem is to do with structuring, but I'm not sure how to solve it, except: 3. Since search engines largely bypass the problem, it doesn't really need to be solved. However, manual authors could possibly aid the process by writing documentation that is more "searchable", only: 4. I don't know how to do that, and the current format is tried and tested for a good reason: it works well either when one tries to learn a system comprehensively, or when one knows a system inside-out but needs a reference. In conclusion I'd say: a) Users: use a search engine. b) Developers: keep writing proper manuals for now. However, well-written responses to mailing list questions are particularly valuable, as are FAQs and cookbook-style documentation based on real-world uses. c) Researchers: More Work Needed. (Or possibly I've just not heard of the amazing research that has already been done, in which case: More Marketing Needed.) GNOME's Project Mallard is the only real-world software I've come across that seems to be an attempt to solve this problem, but then it's far from obvious that new software is actually needed, as opposed to simply new ways of structuring and using documents (i.e. it may be a problem best solved in "human software" rather than "computer software"). -- http://rrt.sc3d.org
better documentation (was: Building prog first)
Hello Reuben, * Reuben Thomas wrote on Sun, Mar 21, 2010 at 07:32:32PM CET: > 1. This is not a fault especially of GNU documentation; rather, GNU > documentation is one of the few places in free and open source > software where one finds properly written manuals. Nice to hear! > 2. I suspect the problem is to do with structuring, but I'm not sure > how to solve it, except: > > 3. Since search engines largely bypass the problem, it doesn't really > need to be solved. However, manual authors could possibly aid the > process by writing documentation that is more "searchable", only: Good indexing is one way to help that (I would hope). Here's an advice for new users: If you have words or phrases that spring to mind when you look for something, and don't find it by those words in any of the indexes (indices?), then please write to bug-automake about it. I'm all for adding more index entries. > b) Developers: keep writing proper manuals for now. However, > well-written responses to mailing list questions are particularly > valuable, as are FAQs and cookbook-style documentation based on > real-world uses. Well, we certainly have too few FAQ entries. Suggestions for more are welcome, too, but I'm usually slow to write them and picky to accept text. ;-) Thanks for your suggestions, Ralf
Re: Public header files
Hi Jef, On 3/17/10 8:23 AM, Jef Driesen wrote: I only need it compiled into my library. The goal is that an application using my library can report the exact revision of the library (for diagnostic purpose). With the solution I outlined in my previous posts, I can already get the "normal" version info (e.g. the major.minor.micro numbers) into a public header file to allow for compile time version checking. Runtime version checking can easily be achieved by adding a mylib_get_version() function to the library. But when building not yet released code, it's more useful to know the exact SCM revision, rather than the version numbers. I compile the svn revision into my program so it can be included in `--version output'. It is based on a solution described here http://www.mhoenicka.de/system-cgi/blog/index.php?itemid=999 I've modified it a bit to avoid unnecessary compilations and to allow building from an 'svn export'. You can see the details on how it is done here http://dev.thep.lu.se/svndigest/browser/trunk/lib/Makefile.am In short, we use two different modes. 1) If we are building from svn wc and 2) if we are building from a tarball or svn export. We test which mode we're in by detecting `$srcdir/.svn' at configure time and create a automake conditional. In case 1) we use svnversion (included in subversion) to create subversion_info.cc from subversion_info.cc.in, whereas in case 2) we do not touch subversion_info.cc. I hope that helps and if you have any question please let me know. Thanks, Peter
Re: Building prog first
Hi Russell, On 3/21/2010 6:14 AM, Russell Shaw wrote: I was limping along for years learning autoconf/make in bits until this tutorial came out Autotools: a practitioner's guide to Autoconf, Automake and Libtool http://www.freesoftwaremagazine.com/books/autotools_a_guide_to_autoconf_automake_libtool I realized a lot of useful things after that. The main thing that makes it easy is that a real project is stepped through with lots of side discussions, and high-level overviews put things in to perspective. I'd really like to have a hard-copy book of that tutorial. Thanks very much for the positive feedback. A much enhanced (and somewhat corrected) version of the book is scheduled to be published in May 2010 by No Starch Press: http://www.amazon.com/Autotools-Practioners-Autoconf-Automake-Libtool/dp/1593272065 Best regards, John After that, i could understand the autoconf manual. I was on dos/windows up to nearly yr2000 or so, so i had to learn unix programming, shell programming, make-file programming, m4, how unix processes work etc, to be able to look in generated Makefiles and "configure" and see from that what errors i was making in configure.ac and automake.am. Learning too many things simultaneously, but i know now.
