pathnames containing spaces
As far as I can tell, it is impossible to get automake to work with pathnames containing spaces. The canonical example is ./configure --prefix="/c/Program Files" make install which will cause make to choke because install will be called with unquoted pathnames. I don't know if there are other examples -- I have never made it past this one. Have I missed something, or is this a bug? It is a serious problem when using MSYS or Cygwin. --Jim Amundson
Re: Calling other external Makefiles and outside Make systems
On Tue, 27 Jan 2004, Ralf Wildenhues wrote:
>
> Ahh, thanks. Well that surely destroys this idea.
>
> But begs for another, config.guess related question:
> Its output being this unstable means: If you want to
> make good use of config.guess, you better be tracking it
> constantly. Ok, I knew this method would be useful to
> but a few packages (most notably libtool[1]), but this
> is a strong reassurance.
>
> Are there auxiliary scripts other than config.{sub,guess}
> which expose complexity rather than hiding it? Which?
These two are the main culprits. Usually when used in conjunction
with libtool. :-)
On the flipside, the config.guess output which is in flux is usually
related to new versions of systems that few people have even heard
about.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
Generating sources
In a project, I am preprocessing the C++ source and headers. That is: foo.ccg -> foo.cc foo.hg -> foo.h Some custom m4 I wrote processes the files with some simple rules: $(top_builddir)/build/classgen.m4f: $(top_srcdir)/build/classgen.m4 $(M4) -P -F $@ $^ %.cc: %.ccg $(top_builddir)/build/classgen.m4f $(M4) -P -R $(top_builddir)/build/classgen.m4f $< > $@ %.h: %.hg $(top_builddir)/build/classgen.m4f $(M4) -P -R $(top_builddir)/build/classgen.m4f $< > $@ Now the complex part ;-) If I have, in my Makefile.am: lib_LTLIBRARIES = libfoo.la libfoo_la_pre_sources = \ foo.ccg \ foo.hg \ libfoo_la_post_sources = \ $(addsuffix .cc,$(basename $(filter %.ccg,$(libfoo_la_pre_sources \ $(addsuffix .h,$(basename $(filter %.hg,$(libfoo_la_pre_sources libfoo_la_SOURCES = \ $(libfoo_la_pre_sources) \ $(libfoo_la_post_sources) \ bar.cc \ bar.h \ If I touch foo.ccg, foo.cc is regenerated and foo.lo rebuilt. However, if I touch foo.hg, foo.h is not rebuilt, which is causing problems (I need to do a manual "make foo.h" every time I alter foo.hg). How should I make this automatic? I thought the above rules would be sufficient, but it does not appear so. Many thanks, Roger -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
Re: Calling other external Makefiles and outside Make systems
* Bob Friesenhahn wrote on Tue, Jan 27, 2004 at 12:03:56AM CET:
> On Mon, 26 Jan 2004, Ralf Wildenhues wrote:
> >
> > Oh, yes, you're right. braino, sorry. This one is not about
> > not changing the subpackage, but about saving space in the combined
> > package. After all, auxiliary scripts with the same name are supposed
> > to be identical, right?
>
> That would be a very poor assumption. Scripts with the same name may
> output different values. For example, an older config.guess script
> may output a different host tripplet for the same OS than a newer
> config.guess, and the version of tools used in the subdirectory key
> off this older host tripplet. They would misbehave if they were
> directed to use the newer config.guess.
Ahh, thanks. Well that surely destroys this idea.
But begs for another, config.guess related question:
Its output being this unstable means: If you want to
make good use of config.guess, you better be tracking it
constantly. Ok, I knew this method would be useful to
but a few packages (most notably libtool[1]), but this
is a strong reassurance.
Are there auxiliary scripts other than config.{sub,guess}
which expose complexity rather than hiding it? Which?
BTW: Thanks for your comments, they really remove some
(unjustified?) expectations a user could get, only
half-understanding the way the autotools work internally.
Regards,
Ralf
[1] libtoolized packages as well, of course, but as long
as that is the only use, the complexity is hidden in
the libtool <-> config.* interface.
Re: Calling other external Makefiles and outside Make systems
On Mon, 26 Jan 2004, Ralf Wildenhues wrote: > > > > I don't understand this. If a third-party package uses an > > auxiliary script, say install-sh, then that third-party package > > already contains install-sh and does not care about the parent's > > auxdir. Am I missing something? What kind of adaptation do you > > want to avoid passing AC_CONFIG_AUX_DIR? > > Oh, yes, you're right. braino, sorry. This one is not about > not changing the subpackage, but about saving space in the combined > package. After all, auxiliary scripts with the same name are supposed > to be identical, right? That would be a very poor assumption. Scripts with the same name may output different values. For example, an older config.guess script may output a different host tripplet for the same OS than a newer config.guess, and the version of tools used in the subdirectory key off this older host tripplet. They would misbehave if they were directed to use the newer config.guess. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Calling other external Makefiles and outside Make systems
* Alexandre Duret-Lutz wrote on Mon, Jan 26, 2004 at 09:56:41PM CET:
> >>> "Ralf" == Ralf Wildenhues <[EMAIL PROTECTED]> writes:
>
> Ralf> A few issues that come to my mind possibly worth
> Ralf> improving (not the documentation, but Auto{make,conf}
> Ralf> with this respect) are
>
> Ralf> - provide a way to communicate the value of AC_CONFIG_AUX_DIR
> Ralf> to sub-package configure scripts (do we need to think about
> Ralf> AC_CONFIG_MACRO_DIR, too?), so they don't need adaptation.
>
> I don't understand this. If a third-party package uses an
> auxiliary script, say install-sh, then that third-party package
> already contains install-sh and does not care about the parent's
> auxdir. Am I missing something? What kind of adaptation do you
> want to avoid passing AC_CONFIG_AUX_DIR?
Oh, yes, you're right. braino, sorry. This one is not about
not changing the subpackage, but about saving space in the combined
package. After all, auxiliary scripts with the same name are supposed
to be identical, right?
> Ralf> - With this respect, what is the value of top_builddir,
> Ralf> top_srcdir and are these properly documented? I only
> Ralf> found out about distdir and top_distdir in the manual.
>
> It's because they really are predefined Autoconf substitutions.
Ok. So they refer to the top of the subpackage trees.
> Anyway, thank you for mentioning that. I really forgot to
> though about VPATH builds while writing this.
>
> Someday I would like to write two introductory sections to the
> manual. One section would be `Automake projects from the user's
> perspective', explaining the various targets available and
> different uses of the GNU build system (cross-compilation, VPATH
> builds, DESTDIR installs). I don't really expect end-users to
> read the Automake manual, but it is a nice way to introduce
> these concept before showing how they work. The other section
> would be the `developer's perspective'. It would explain how a
> project is usually organized, the purpose of each autotool, and
> how everything fits to achieve the feature listed in the
> previous section. Perhaps this second section will need to be
> split in many sub-sections, explaining how DESTDIR installs,
> cross-compilation, VPATH builds, etc. work. The discussion
> about srcdir/top_srcdir/top_buildir belongs there, IMHO.
ACK. This would IMHO be a worthwhile goal, but a lot of work, too.
The top_{src,build}dir thing above is one of those issues deeply hidden
from users. For example, until your explanation I had no idea what
part of the autotools created it, and -- now the mere autotools user
speaking -- frankly, I didn't want to know.
> Ralf> Other than that, a few language hints (disclaimer: from a
> Ralf> non-native):
>
> Thanks again. The only changes I didn't include are the colons,
> but that's a matter of taste and if someone insists I can put
> them in.
That choice is fine.
> Here is a new version of that section, with additions
> highlighted on the left.
Looks good to me, so only typos:
[ snip lots ]
>
> Here are two other ideas. If GNU make is assumed, one possibility is
> to add to that subdirectory a `GNUmakefile' that defines the required
> | targets and include the third-party `Makefile'. For this to work in
> | VPATH builds, `GNUmakefile' must lie in the build directory; the
> | easiest way to do this is to write a `GNUmakefile.in' instead, and have
> | it processed with `AC_CONFIG_FILES' from the outer package. For
> | example if we assume `Makefile' defines all targets except the
^
comma here
> | documentation targets, and that the `check' target is actually called
> | `test', we could write `GNUmakefile' (or `GNUmakefile.in') like this:
[ snip ]
> Pushing this idea to the extreme, it is also possible to ignore the
> subproject build system and build everything from this proxy
> | `Makefile.am'. This might sounds very sensible if you need VPATH
^
sound
> | builds but the subproject does not support them.
Regards,
Ralf
Teleboerse - Germany
Dear Ladies and Sirs, Thank you very much for your enqiry . We are pleased to inform you about us. We are a German telecommunication company spezialised in production and sale of international calling cards. At the moment we are looking for business partners, wholesalers or agents who are interested in cooperating with us. Your customers are able to reduce their telephone costs up to 50 % and enjoy a high quality standard with us. Your advantage is having high profits in this branch. We work all over the world. Using our competence you not only can establish your own business in your country also everywhere you have got business relations. Let's be together successfully !!! You just need to fill out our convienient Enqiry form from our homepage www.teleboerse-germany.de button distributor and send it to us. After getting your informations we will send you immediatly our free and indetermined offer. We are sure that we can successfully conquer the market in your country together. If you have any questions or proposals please do not hesitate to contact us. Telephone: +49 / 341 / 306 17 23 Telefax:+49 / 341 / 306 17 24 E-Mail: [EMAIL PROTECTED] Website:www.teleboerse-germany.de We are already looking forward having a longtime and successful partnership with you. Yours faithfully TELE BOERSE Germany
Re: Calling other external Makefiles and outside Make systems
>>> "Ralf" == Ralf Wildenhues <[EMAIL PROTECTED]> writes:
[...]
Ralf> A few issues that come to my mind possibly worth
Ralf> improving (not the documentation, but Auto{make,conf}
Ralf> with this respect) are
Ralf> - provide a way to communicate the value of AC_CONFIG_AUX_DIR
Ralf> to sub-package configure scripts (do we need to think about
Ralf> AC_CONFIG_MACRO_DIR, too?), so they don't need adaptation.
I don't understand this. If a third-party package uses an
auxiliary script, say install-sh, then that third-party package
already contains install-sh and does not care about the parent's
auxdir. Am I missing something? What kind of adaptation do you
want to avoid passing AC_CONFIG_AUX_DIR?
Ralf> - With this respect, what is the value of top_builddir,
Ralf> top_srcdir and are these properly documented? I only
Ralf> found out about distdir and top_distdir in the manual.
It's because they really are predefined Autoconf substitutions.
Anyway, thank you for mentioning that. I really forgot to
though about VPATH builds while writing this.
Someday I would like to write two introductory sections to the
manual. One section would be `Automake projects from the user's
perspective', explaining the various targets available and
different uses of the GNU build system (cross-compilation, VPATH
builds, DESTDIR installs). I don't really expect end-users to
read the Automake manual, but it is a nice way to introduce
these concept before showing how they work. The other section
would be the `developer's perspective'. It would explain how a
project is usually organized, the purpose of each autotool, and
how everything fits to achieve the feature listed in the
previous section. Perhaps this second section will need to be
split in many sub-sections, explaining how DESTDIR installs,
cross-compilation, VPATH builds, etc. work. The discussion
about srcdir/top_srcdir/top_buildir belongs there, IMHO.
Ralf> Other than that, a few language hints (disclaimer: from a
Ralf> non-native):
Thanks again. The only changes I didn't include are the colons,
but that's a matter of taste and if someone insists I can put
them in.
Here is a new version of that section, with additions
highlighted on the left.
Third-Party `Makefile's
===
In most projects all `Makefile's are generated by Automake. In some
cases, however, projects need to embed subdirectories with handwritten
`Makefile's. For instance one subdirectory could be a third-party
project with its own build system, not using Automake.
It is possible to list arbitrary directories in `SUBDIRS' or
`DIST_SUBDIRS' provided each of these directories has a `Makefile' that
recognizes all the following recursive targets.
When a user runs one of these targets, that target is run recursively
in all subdirectories. This is why it is important that even
third-party `Makefile's support them.
`all'
Compile the entire package. This is the default target in
Automake-generated `Makefile's, but it does not need to be the
default in third-party `Makefile's.
`distdir'
Copy files to distribute into `$(distdir)', before a tarball is
constructed. Of course this target is not required if the
`no-dist' option (*note Options::) is used.
| The variables `$(top_distdir)' and `$(distdir)' (*note Dist::)
| will be passed from the outer package to the subpackage when the
| `distdir' target is invoked. These two variables have been
| adjusted for the directory which is being recursed into, so they
| are ready to use.
`install'
`install-data'
`install-exec'
`uninstall'
Install or uninstall files (*note Install::).
`install-info'
Install only the Texinfo documentation (*note Texinfo::).
`installdirs'
Create install directories, but do not install any files.
`check'
`installcheck'
Check the package (*note Tests::).
`mostlyclean'
`clean'
`distclean'
`maintainer-clean'
Cleaning rules (*note Clean::).
`dvi'
`pdf'
`ps'
`info'
`html'
Build the documentation in various formats (*note Texinfo::).
`tags'
`ctags'
Build `TAGS' and `CTAGS' (*note Tags::).
If you have ever used Gettext in a project, this is how it works.
The `Makefile's in the `po/' and `intl/' directories are handwritten
`Makefile's that implement all these targets. That way they can be
added to `SUBDIRS' in Automake packages.
Directories which are only listed in `DIST_SUBDIRS' but not in
`SUBDIRS' need only the `distclean', `maintainer-clean', and `distdir'
rules (*note Top level::).
Usually, many of these rules are irrelevant to the third-party
subproject, but they are required for the whole package to work. It's
OK to have a rule that does nothing, so if you are integrating a
third-party project with no documentation or tag support, you could
Re: Calling other external Makefiles and outside Make systems
* Alexandre Duret-Lutz wrote on Sun, Jan 25, 2004 at 10:55:46AM CET:
>
> Here is proposed section about this for the manual. Please let
> me know if this answers your question, or if it can be improved
> in any way (including English mistakes).
I'm not John, but I'll answer anyway. I like the section, especially
the idea of possibly not having to modify the subproject at all.
A few issues that come to my mind possibly worth improving (not the
documentation, but Auto{make,conf} with this respect) are
- provide a way to communicate the value of AC_CONFIG_AUX_DIR
to sub-package configure scripts (do we need to think about
AC_CONFIG_MACRO_DIR, too?), so they don't need adaptation.
- With this respect, what is the value of top_builddir, top_srcdir
and are these properly documented? I only found out about
distdir and top_distdir in the manual.
Other than that, a few language hints (disclaimer: from a non-native):
> `installdirs'
> Create install directories, but do not install any file.
files?
> `dvi'
> `pdf'
> `ps'
> `info'
> `html'
> Build the documentation in various format (*note Texinfo::).
formats
>If you have ever used Gettext in a project, this is how it works.
I would use a colon (`:') at the end of this sentence.
> The `Makefile's in the `po/' and `intl/' directories are handwritten
> `Makefile's that implement all these targets. That way they can be
> added to `SUBDIRS' in Automake packages.
>
>Directories which are only listed in `DIST_SUBDIRS' but not in
> `SUBDIRS', need only the `distclean', `maintainer-clean', and `distdir'
^
AFAIK no comma here (the subclause is a restrictive modifier).
> rules (*note Top level::).
>
>Usually, many of these rules are irrelevant to the third-party
> subproject, but they are required for the whole package to work. It's
> OK to have a rule that does nothing, so if you are integrating a
> third-party project with no documentation or tag support, you could
> simply augment its `Makefile' as follows:
>
> EMPTY_AUTOMAKE_TARGETS = dvi pdf ps info html tags ctags
> .PHONY: $(EMPTY_AUTOMAKE_TARGETS)
> $(EMPTY_AUTOMAKE_TARGETS):
>
>It is sometimes inconvenient to modify a third-party `Makefile' to
> introduce these required targets. For instance one may want to keep
> the third-party sources untouched to ease upgrade to new versions.
>
>Here are two other ideas. If GNU make is assumed, one possibility is
`:' after ideas, as above.
> to add to that subdirectory a `GNUmakefile' that defines the required
> targets and include the third-party `Makefile'. For example if we
> assume `Makefile' defines all targets except the documentation targets,
> and that the `check' target is actually called `test', here the
> `GNUmakefile' we could write:
... target is actually called `test', we could write a `GNUmakefile'
like this:
> # First, include the real Makefile
> include Makefile
> # Then, define the other targets needed by Automake Makefiles.
> .PHONY: dvi pdf ps info html check
> dvi pdf ps info html:
> check: test
>
>A similar idea, that does not use `include' is to write a proxy
^
AFAIK no comma here (or put one there and one after `include', since
here the modification is rather unrestrictive).
> `Makefile' that dispatches rules to the real `Makefile', either with
> `$(MAKE) -f Makefile.real $(AM_MAKEFLAGS) target' (if it's OK to rename
> the original `Makefile') or with `cd subdir && $(MAKE) $(AM_MAKEFLAGS)
> target' (if it's OK to store the subdirectory project one directory
> deeper).
[...]
Regards,
Ralf
AWARD WINNING NOTIFICATION LOTTERIA.
LOTTERY LA PRIMITIVA. C/BUSMAN EL BUENO,137 MADRID - ESPANA FROM: THE DESK OF THE PROMOTIONS MANAGER, INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPARTMENT ATTENTION: (CONGRATULATION) "AWARD NOTIFICATION FINAL NOTICE." THROUGH THIS MEDIUM WE WISH TO NOTIFY YOU ON THE RELEASE OF THE RESULT OF THE ELGORDO DE LA PRIMITIVA SPANISH PROGRAM HELD ON 16TH JANUARY 2004,SHOULD THERE BE ANY DISCREPANCY OF NUMBERS AND ADDRESS, PLEASE DO NOT HESITATE TO INFORM LUIS SANTIAGO(LOTTERY AGENTS) THAT ENTERED YOUR NAMES AS ONE OF THEIR CLIENTS WITH REFERENCE NUMBERS EL/778654390213/03 AND BATCH NUMBER 621/1423/DPR. IN THE FIFTH SERIES FROM A POOL OF 75 MILLION,IN CASH AMONG THE 26 PARICIPATING FINALIST PLAYING 6,000 TICKETS YOUR TICKET NUMBER WHICH IS 262-08177300-189,SERIAL NO.99375-0 AND THE WINNING NO. 07-08-12-16-26-46 HAS BEEN APPROVED FOR THE LUMPSUM PAYMENT OF OF 625,000.34C IN CASH CREDIT TO FILE REFERENCE NUMBER BQ/8366439644/03. CONGRATULATIONS. DUE TO MIX UP OF NUMBERS AND E-MAIL ADDRESSES,I WOULD ADVICE THAT YOU KEEP THIS AWARD TOP SECRET UNTIL YOUR CLAIM HAS BEEN CONFIRMED AND PRIZE AWARD PAID.THIS IS PART OF OUR SECURITY PROTOCOL TO AVOID DOUBLE CLAIMING OR UNWARRANTED TAKING ADVANTAGE OF THE ABOVE SITUATION. PLEASE BE ADVISED THAT YOUR FUND HAS BEEN DEPOSITED IN OUR CORRESPONDING SECURITY/INSURANANCE COMPANY IN YOUR FAVOUR. TO BEGIN YOUR CLAIM,PLEASE CONTACT YOUR AGENT MR LUIS SANTIAGO THE MANAGING DIRECTOR OF LUIS SANTIAGO SL(LOTTERY AGENTS) ON TELEPHONE NO. +34-654-225-918, OR EMAIL AT [EMAIL PROTECTED] THE PROCESSING AND REMITTANCE OF YOUR FUND. THE DEADLINE FOR THIS NOTICE IS 14TH FEBUARY 2004 AFTER WHICH THE FUNDS WILL BE RETURNED TO THE MINISTERIO DE ECONOMIA Y HACIENDA AS UNCLAIMED. CONGRATULATIONS ONCE AGAIN FROM ALL MEMBERS OF OUR STAFF AND THANK YOU FOR YOUR INTEREST IN ELGORDO LOTTERY SPANISH SWEEPSTAKE CO.S.L. YOURS FAITHFULLY, MANUEL GUSTAVO
