Re: Implementing Automake in Scheme
Greetings, On Thu, 5 Aug 2004, Luis Araujo wrote: I email to ask you for further information about a task in the section GNU Help Wanted in savannah, named Implement automake in Scheme , there is a brief description I didn't know there was such a thing as the `GNU Help Wanted' list, but I've long thought such a project would be an excellent idea. It's a pretty natural language for such a task, and quite a few of the important bits of automake.in are, it seems to me, written in a pretty functional style anyway. And scsh is POSIX, portable, and pretty lightweight. Not that I'm volunteering, mind On 2004 Aug 5 , at 22.05, Bob Friesenhahn wrote: [...] back in the days when Guile Scheme were described to be superior to Perl and Tcl. lots-of-stuff-from-me-I-thought-better-of-for-obvious-reasons-but... It is not a universally held opinion that Perl and Tcl are good implementation languages for medium- to large-sized projects. All the best, Norman -- -- Norman Gray : Physics Astronomy, Glasgow University, UK http://www.astro.gla.ac.uk/users/norman/ : www.starlink.ac.uk
Why Pay M0re? x1ps
User ID: 0 diffuse Date: Fri, 06 Aug 2004 22:49:27 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=--96485840200044712 96485840200044712 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Aspell-user The Best 0n|ine Phar-macy is here. Why pay m0re when you can enjoy at a specia| disc0unt? -Cia|is -Via-gra -Vi0xx -S0ma and many many more! Visit Us t0day! http://www.worldwidemedstoday.com?wid=18 This 0ne-time mai-|ing. N0 re m0val are requ|red XrQX5CFPSBGgxSo4eTQ5VbmCtDvf2yVa4i1nd3IZbhHA7sEknsQX4wrEVgG 96485840200044712--
Distributing BUILT_SOURCES dependencies and not target
Hi, I am compiling a project with a swig generated file. Swig is a tool that takes a foo.i file and generates a foo_wrap.cxx (it can do more but no our concerne here ;-)). In my Makefile.am, I put: line 1: foo_wrap.cxx: foo.i line 2: $SWIG -c++ -python foo.i line 3: line 4: BUILT_SOURCES: foo_wrap.cxx line 5: libfoo.la_SOURCES: foo_wrap.cxx line 6: line 7: dist_data_DATA: foo.i First question: I put line 7 because I want the .i file to be distributed so people can re-generate the .cxx file with their own version of swig ($SWIG is set by a m4 command SWIG_PROG in configure.in). Is this the correct way to do it. It seems make dist produce tarballs with the file in it som I am happy. Second question: The problem is that foo_wrap.cxx gets distributed too. And since it is always more recent that .i file after I ran make. I don't have the expected behaviour. Downloaders of the lib won't get the foo_wrap.cxx regenerated. How do I remove this file from the dist. Third question: with this Makefile.am, make dist produce a tarball that I can install, compile, etc... but make distcheck complains that it cannot find foo.i!! But it *is* in the tarball?!? I don't get at all what's happening here. Thanks for the help.
Re: Implementing Automake in Scheme
On Sat, 7 Aug 2004, Norman Gray wrote: On Thu, 5 Aug 2004, Luis Araujo wrote: I email to ask you for further information about a task in the section GNU Help Wanted in savannah, named Implement automake in Scheme , there is a brief description I didn't know there was such a thing as the `GNU Help Wanted' list, but I've long thought such a project would be an excellent idea. It's a pretty natural language for such a task, and quite a few of the important bits of automake.in are, it seems to me, written in a pretty functional style anyway. And scsh is POSIX, portable, and pretty lightweight. Automake is already written. It took years. Perl is already installed on most machines. Scheme is not. It is surely a waste of time to re-implement something simply because it does not use a FSF-preferred language. There must be something more useful for volunteers to work on. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: [help-texinfo] Re: translating automake infopage
I wonder if tools similar to gettext exist for manuals? FWIW, I have never seen any. Something based on wdiff might be better than straight diff. E.g., does `info' supports several translated versions of a manual? There is no special support for translations in the Texinfo system. In fact, there is little support for languages other than English (although some non-English manuals have been written). This is of course a very serious deficiency, but it's not easy to remedy, and I regretfully have not had time to do much about it. If yes, where should they be installed and how should they be named? There is a French translation of the Info manual. It's named info-fr.texi and info can access it just like any other manual. FWIW. A better approach would probably be $(infodir)/fr/info.texi. But this actually requires changing the code to figure out where to look under what circumstances, and thus hasn't been done. (I see nothing about this in the Texinfo manual, but maybe there are plans for this.) It's come up many times. Wish I had better news to report.
Re: Distributing BUILT_SOURCES dependencies and not target
Hi Xavier, On Sat, 07 Aug 2004 16:00:39 +0200, Xavier Dcoret wrote: ... line 4: BUILT_SOURCES: foo_wrap.cxx line 5: libfoo.la_SOURCES: foo_wrap.cxx line 6: line 7: dist_data_DATA: foo.i ... Second question: The problem is that foo_wrap.cxx gets distributed too. And since it is always more recent that .i file after I ran make. I don't have the expected behaviour. Downloaders of the lib won't get the foo_wrap.cxx regenerated. How do I remove this file from the dist. I am using: dist-hook: for i in _built_sources_pad $(BUILT_SOURCES);do \ $(RM) $(distdir)/$$i; \ done Regards, Lace -- Jan Kratochvil; Captive: free r/w NTFS Filesystem; http://www.jankratochvil.net/
Re: Distributing BUILT_SOURCES dependencies and not target
Xavier == Xavier Décoret [EMAIL PROTECTED] writes: Xavier Hi, Xavier I am compiling a project with a swig generated file. Swig is a tool Xavier that takes a foo.i file and generates a foo_wrap.cxx (it can do more Xavier but no our concerne here ;-)). Xavier In my Makefile.am, I put: Xavier line 1: foo_wrap.cxx: foo.i Xavier line 2: $SWIG -c++ -python foo.i Xavier line 3: Xavier line 4: BUILT_SOURCES: foo_wrap.cxx Xavier line 5: libfoo.la_SOURCES: foo_wrap.cxx Xavier line 6: Xavier line 7: dist_data_DATA: foo.i This should be something like foo_wrap.cxx: $(srcdir)/foo.i $(SWIG) -c++ -python -o $@ $(srcdir)/foo.i whereveryouwantitinstalled_LTLIBRARIES = libfoo.la nodist_libfoo_la_SOURCES = foo_wrap.cxx CLEANFILES = $(nodist_libfoo_la_SOURCES) EXTRA_DIST = foo.i if you want foo_wrap.cxx to be rebuilt on the user-side and not distributed, or something like $(srcdir)/foo_wrap.cxx: $(srcdir)/foo.i $(SWIG) -c++ -python $(srcdir)/foo.i whereveryouwantitinstalled_LTLIBRARIES = libfoo.la libfoo_la_SOURCES = $(srcdir)/foo_wrap.cxx MAINTAINERCLEANFILES = $(srcdir)/foo_wrap.cxx EXTRA_DIST = foo.i if you want to distribute foo_wrap.cxx so users do not need to have SWIG installed. BUILT_SOURCE is not needed here since foo_wrap.cxx is an explicit dependency of libfoo.la. Here is a more concrete setup I'm using to build two interdependent Python modules using SWIG and Libtool. I decided to distribute the SWIG wrapper sources so as not to require SWIG on the build host. | AM_CPPFLAGS = -I$(PYTHONINC) -I$(top_srcdir)/src $(BUDDY_CPPFLAGS) | | EXTRA_DIST = ltihooks.py spot.i buddy.i | python_PYTHON = $(srcdir)/spot.py $(srcdir)/buddy.py | pyexec_LTLIBRARIES = _spot.la _buddy.la | lib_LTLIBRARIES = libspotswigpy.la | | libspotswigpy_la_SOURCES = libpy.c | libspotswigpy_la_CFLAGS = -DSWIG_GLOBAL | libspotswigpy_la_LDFLAGS = -avoid-version | | _spot_la_SOURCES = $(srcdir)/spot_wrap.cxx | _spot_la_LDFLAGS = -avoid-version -module | _spot_la_LIBADD = $(top_builddir)/src/libspot.la libspotswigpy.la | | $(srcdir)/spot_wrap.cxx: $(srcdir)/spot.i | swig -noruntime -c++ -python -I$(srcdir) -I$(top_srcdir)/src $(srcdir)/spot.i | | $(srcdir)/spot.py: $(srcdir)/spot.i | $(MAKE) $(AM_MAKEFLAGS) spot_wrap.cxx | | _buddy_la_SOURCES = $(srcdir)/buddy_wrap.cxx | _buddy_la_LDFLAGS = -avoid-version -module $(BUDDY_LDFLAGS) | _buddy_la_LIBADD = libspotswigpy.la | | $(srcdir)/buddy_wrap.cxx: $(srcdir)/buddy.i | swig -noruntime -c++ -python $(BUDDY_CPPFLAGS) $(srcdir)/buddy.i | | $(srcdir)/buddy.py: $(srcdir)/buddy.i | $(MAKE) $(AM_MAKEFLAGS) buddy_wrap.cxx | | MAINTAINERCLEANFILES = \ | $(srcdir)/spot_wrap.cxx $(srcdir)/spot.py \ | $(srcdir)/buddy_wrap.cxx $(srcdir)/buddy.py Xavier First question: I put line 7 because I want the .i file to be Xavier distributed so people can re-generate the .cxx file with their own Xavier version of swig ($SWIG is set by a m4 command SWIG_PROG in Xavier configure.in). Is this the correct way to do it. It seems make dist Xavier produce tarballs with the file in it som I am happy. `dist_data_DATA = foo.i' also means to install foo.i in $(datadir)/; I don't think you want that. Use EXTRA_DIST. Xavier Second question: The problem is that foo_wrap.cxx gets distributed Xavier too. And since it is always more recent that .i file after I ran Xavier make. I don't have the expected behaviour. Downloaders of the lib Xavier won't get the foo_wrap.cxx regenerated. How do I remove this file from Xavier the dist. *_SOURCES are distributed by default, and you should use nodist_*_SOURCES otherwise. Xavier Third question: with this Makefile.am, make dist produce a tarball Xavier that I can install, compile, etc... but make distcheck complains that Xavier it cannot find foo.i!! But it *is* in the tarball?!? I don't get at Xavier all what's happening here. It cannot find foo.i in the build directory because it is in the source directory. -- Alexandre Duret-Lutz
Re: Distributing BUILT_SOURCES dependencies and not target
Jan == Jan Kratochvil [EMAIL PROTECTED] writes: Jan Hi Xavier, Jan On Sat, 07 Aug 2004 16:00:39 +0200, Xavier Décoret wrote: Jan ... line 4: BUILT_SOURCES: foo_wrap.cxx line 5: libfoo.la_SOURCES: foo_wrap.cxx line 6: line 7: dist_data_DATA: foo.i Jan ... Second question: The problem is that foo_wrap.cxx gets distributed too. And since it is always more recent that .i file after I ran make. I don't have the expected behaviour. Downloaders of the lib won't get the foo_wrap.cxx regenerated. How do I remove this file from the dist. Jan I am using: Jan dist-hook: Jan for i in _built_sources_pad $(BUILT_SOURCES);do \ Jan $(RM) $(distdir)/$$i; \ Jan done It's always a bad idea to lie to Automake (i.e. pretend that a file is to be distributed, and remove it in its back), especially when you have ways to express the truth (using dist_/nodist_). -- Alexandre Duret-Lutz
the correct rm macro in automake
Hi, I am writing a install-exec-hook and the appropriate uninstall-hook. The former simply makes a copy of installed lib somewhere else, and the later needs to delete it. For that I simply wrote: uninstall-hook: rm -f foo.so What is the correct variable to ask for removal of a file. Is this $(rm) or something like this? Thanks.
