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
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
simply augment
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
* 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
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.
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.
