make love tonight 美女图片
click here to see more °´ÕâÀï½øÈë
Orjinal Palit Daytona TNT2 M64 AGP 32MB ---> 25$
INTERNET DEN DAHA UCUZA ALýN Ýnternetden alýndýðýndaki fiyatý Telefon ile alýndýðýndaki fiyatý Orijinal Palit Daytona TNT2 M64 AGP 32MB Ekran Kartý 25$ 26$ www.picom.com.troem.picom.com.trElektronik Posta gönderilmesini istemiyor iseniz; Lutfen linki takip ederek, isteðinizi gerçeklestirin. Daha sonra karar deðiþtirip tekrar e-mail almak isteyebilirseniz, bu maili lutfen silmeyiniz. Ayný link den tekrar hesabýnýzý açabilirsiniz. http://cari.picom.com.tr/e-mail.picom?user=gbbWrxNM0hTz5qv1&password=CgAK1ZVJJNcW5qG5 If you don't want to recieve any e-mails from Picom, then please proceed your wishes following the above link.If you may change your mind and may want to recieve later, please keep this mail. You may open your lock of send mail following to the same link. This is exactly online price list which is updating by all the price tracking team on the working hours. You can reach any time to the same list from www.picom.com.tr.
make love tonight 美女图片
click here to see more °´ÕâÀï½øÈë
Re: Feature request: meta files & wildcards (once again)
> "Alex" == Alex Hornby <[EMAIL PROTECTED]> writes: Alex> I suppose automake could be enhanced so that it automatically Alex> knew which files are BUILT_SOURCES by looking back through the Alex> suffix rules. Then the small overhead of listing them twice Alex> would be removed. BUILT_SOURCES are built early, before anything else happens. It isn't clear you always want this for sources that are built during the build process. (I don't have an example though.) I know I've thought of it before, though, since this is in TODO: * notice when a .c file is a target somewhere, and auto-add it to BUILT_SOURCES Tom
Re: installing stripped kernel modules
> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes:
>> You could set the INSTALL* macros at configure time to exactly what
>> you want. You can even write your own install program, or modify
>> install-sh (actually with install-sh you can set STRIPPROG in the
>> environment).
Harlan> I'm not sure this is possible:
Harlan> [ ... ]
Harlan> so the value of the INSTALL_STRIP_FLAG is hardwired by the
Harlan> install-strip target and is used by the hardwired library
Harlan> install ... wait a minute, this may not be a problem for *me*
Harlan> because I'm not installing a library (probably - I haven't
Harlan> looked that far yet).
Ok, all I meant was:
* Either set the INSTALL* variables by hand (eg to a hacked
install-sh), or
* Set STRIPPROG to the program you want to use to strip ("strip
--my-options"), and
* Don't use `install-strip', which won't do what you want.
Harlan> So with kmod_PROGRAMS = foo.o it looks like the .o gets
Harlan> installed as a *Program* target thru the *data* rule
Harlan> automagically by automake:
Harlan> install-data-am: install-kmodPROGRAMS
Ok, this is actually "wrong". `install-data' shouldn't be installing
architecture-specific files. It does because of the name `kmoddir'.
You actually "want" to name it `kmodexecdir'.
Harlan> install-strip:
Harlan> $(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
Harlan> INSTALL_STRIP_FLAG=-s \
Harlan> `test -z '$(STRIP)' || \
Harlan> echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
install will invoke install-data, so I think the `-s' will be passed
down.
>> Or if you always want to strip at install time you could use an
>> install-exec-hook and strip the executables after they are installed.
Harlan> Unfortunately this is not the case...
Ok. That does make things harder. Basically what you want is
something we've never had to handle before. So things are tough. I
wonder if there's an efficient way to add a per-program
install-strip-flag.
Harlan> Something "classy" to define and augment/override "primaries"
Harlan> would be useful, but probably difficult.
Yeah.
Tom
Re: What's this aclocal error mean?
> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: adl> aclocal does not search configure.in for macro definitions. This seems like an odd wart. I've submitted a PR. Tom
Re: per object cflags
> "Rob" == Robert Collins <[EMAIL PROTECTED]> writes: Rob> Are there any plans to allow per object CFLAGS (and CXXFLAGS...)? You mean per-`.o'? There aren't any concrete plans. Offhand I can't think of any barrier to doing it though. In fact it might be easy. (Explaining it might be hard.) Could you submit a PR for this feature? Rob> Currently I compile those source files with manual rules, Rob> but... that means that the dependency tracking stuff doesn't work Rob> for them... Yeah, this is a problem. It would be nice if we had a relatively easy way to handle situations where you want the full rule with some minor tweak. Duplicating the code is pretty bad, since it is complicated and changes from time to time. Tom
Re: building/installing Python modules?
> "Christoph" == <[EMAIL PROTECTED]> writes: Christoph> I thought of using the auto* tools for building python Christoph> extensions a few months ago now, but since i was using Christoph> swig, i did not know how to integrate the swig meta files Christoph> (*_wrap.c) into the auto* stuff - the way to write a script Christoph> which edits the Makefile.in does not look practical to me. We're always interested in having automake work well with other free software projects. I've never used swig, so I don't know exactly what is required. But changes here, if they are useful, are possible. Tom
Re: INSTALL_STRIP_FLAG is apparently hardwired.
> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes:
Harlan> Would it be OK to say:
Harlan> INSTALL_STRIP_FLAG=$${INSTALL_STRIP_FLAG:-s} \
Harlan> in lib/am/install.am?
I wouldn't have a problem with this. Alexandre?
We'd need to document INSTALL_STRIP_FLAG.
Harlan> - if I "quoted" that right
Harlan> - if ${foo:-value} is sufficiently portable
I think ${INSTALL_STRIP_FLAGS-"-s"} is closer.
Harlan> - if it's Bad to leave INSTALL_STRIP_FLAGS set in general
I don't understand.
Tom
Re: automake: /tmp/examplelib-0.2.0/examplelib-0.2.0.am: `/tmp/examplelib-0.2.0/examplelib-0.2.0.am' does not exist
> ">" == Ben Martin <[EMAIL PROTECTED]> writes: >> I upgraded my autotools to rawhide (and since have reverted to the 7.2 >> ones and many other versions) and can not get a stable automake 1.4 >> again:( I didn't see an answer to this. Offhand I can't say what the problem might be. Perhaps it is some packaging error. (Don't be deceived by my email address. I don't deal with automake in the Red Hat OS releases.) Tom
Re: automake and AC_CONFIG_FILES($foo)
> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes: Harlan> One of the biggest apparent hurdles is that these folks would Harlan> benefit from having a single monolithic Makefile.am at the top Harlan> level, as that would provide the best parallel makes, provide Harlan> the best library dependency stuff, run the fastest, etc. Harlan> OTOH, it would be Difficult to coordinate changes to this Harlan> Makefile.am (lots of developers) and they still want the Harlan> ability to run a make in a subdir. These goals (monolithic Makefile.am and run make in a subdir) are really not compatible. The `import' plan would let you run `make subdir/all', which is similar, but that plan is still on the drawing boards. Harlan> Other problems include about 160 Makefile.am's that use Harlan> automake conditionals to decide if certain _PROGRAMS need to Harlan> be made or not, and in many cases, which target-specific Harlan> _SOURCES need to be used. Wow. Harlan> I arrived just after the conversion from automake-1.4 to 1.5, Harlan> and based on my current efforts I'm probably going to Harlan> recommend we look at upgrading to 1.6.1 just to quiet some of Harlan> the "automake does not support XXX being defined Harlan> conditionally" messages. I think that's smart. From what I know right now I'd say 1.6.1 is a lot less buggy and difficult to use than 1.5. Harlan> I'm actually considering looking at keeping the Makefile.am's Harlan> in each subdir and looking at AutoXport to combine this info Harlan> into a top-level .xml file and then see if that .xml file can Harlan> be easily converted to a Jakarta/ant build.xml file. That sounds frightening. I haven't looked at Ant too much. I read a bit about it last week. It sounds like it doesn't really track dependencies at all. Perhaps I missed that section of the manual. Tom
Re: Antwort: Re: Feature request: meta files & wildcards (once again)
> "Christoph" == <[EMAIL PROTECTED]> writes: Christoph> Yes and no. Take the example of QT's moc files. They have Christoph> to be generated from .h files, if the class defined in the Christoph> .h file does mention a Q_OBJECT macro. I would love to have Christoph> something in my Makefiles which greps for the string Christoph> Q_OBJECT in all .h files this directory contains. For each Christoph> file where this is found, the moc has to be started. I Christoph> think this is not possible at the current time without Christoph> writing a script which edits the Makefile.in's (this is Christoph> what KDE Developers do). It would have been friendlier to automake to pick a new extension. Alas. I would prefer if there were some way that automake could accomodate KDE without requiring rewriting the Makefile.in. That seems pretty fragile. Tom
Re: lex & yacc with C++ projects
> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes: Ralf> Yes, naming the sources .ll rsp. yy is supposed to handle this. Ralf> But I found this not to be actually functional with different Ralf> versions of automake, so YMMV. Yeah, there have been various reports and patches about this, but I've never made the time to fully investigate :-( Tom
Re: automake reports .lo file created with and without libtool
> "Richard" == Richard Boulton <[EMAIL PROTECTED]> writes: [ Sorry for the delay in my reply. Lately, as you probably can tell, I've only been reading automake email intermittently. ] Richard> sbin_PROGRAMS = camel-lock-helper ... Richard> lib_LTLIBRARIES = libcamel.la Richard> libcamel_la_SOURCES = ... camel-lock.c ... Richard> camel_lock_helper_SOURCES = ... camel-lock.c ... Richard> Perhaps the appropriate solution is for automake to notice Richard> the conflict, and automatically use libtool to compile the Richard> objects for camel-lock-helper and to link it. You can already work around this in a couple ways. One way is to put camel-lock.c into a convenience library that is then used by both libcamel and camel-lock-helper. Another way is to introduce per-exe or per-library CFLAGS for one of the programs and thus cause the .o to be renamed. Automatically fixing the problem in the general case is probably hard. Tom
Re: Antwort: Re: Feature request: meta files & wildcards (once again)
> "Alex" == Alex Hornby <[EMAIL PROTECTED]> writes: Alex> Suffix rules should be portable to all makes, its pattern rules Alex> that aren't available everywhere. Nowadays we could probably implement pattern rules purely in automake. Back in the old days we didn't have the machinery to allow this. Automake itself was too primitive. But now it would be more possible, if someone were motivated. Maybe this would help with the longstanding CORBA problems? Tom
