search for: autofoo

Hello. I see many discrepancies in config.h file generated by CMake and autoheader. Most of them are following: In autofoo-generated config: > /* Define to 1 if you have the `<name>' function. */ > #define HAVE_<name> 1 > but in CMake-generated: > #undef HAVE_<name> > This happens because in config.h.cmake (config.h.in analog) these functions just are not checked for. Another dif...

On Jan 4, 2011, at 7:45 AM, arrowdodger wrote: > Hello. I see many discrepancies in config.h file generated by CMake and autoheader. > > Most of them are following: > In autofoo-generated config: > /* Define to 1 if you have the `<name>' function. */ > #define HAVE_<name> 1 > but in CMake-generated: > #undef HAVE_<name> > This happens because in config.h.cmake (config.h.in analog) these functions just are not checked for. > We may...

...yped the message. ----- Forwarded Message ---- > From: Samuel Crow <samuraileumas at yahoo.com> > To: Ruben Van Boxem <vanboxem.ruben at gmail.com> > Sent: Wed, January 5, 2011 3:38:21 PM > Subject: Re: [LLVMdev] include/Config/config.h discrepancies between CMake and >autofoo builds > > > > > > ----- Original Message ---- > > From: Ruben Van Boxem <vanboxem.ruben at gmail.com> > > To: Óscar Fuentes <ofv at wanadoo.es> > > Cc: llvmdev at cs.uiuc.edu > > Sent: Wed, January 5, 2011 3:10:29 PM > > Subject: R...

2011/1/5 Óscar Fuentes <ofv at wanadoo.es>: > Ruben Van Boxem <vanboxem.ruben at gmail.com> writes: > >> Yeah that's the two different ones I mean. Everything MS (intrinsics, >> language features etc...) is purely version-bound, so I don't even get >> why CMake insists on checking every known function prototype of for >> example "recv"

arrowdodger <6yearold at gmail.com> writes: >> Or to say it with other words: patches welcome. > > So, how should i proceed? Make CMake-generated config to be identical to > autotools one? That would be a good thing. Please note that some checks are a bit tricky. A function that on platform A is on header foo.h on another platform may be on bar.h. Furthermore, cmake's

Eric Christopher <echristo at apple.com> writes: >>> Or cleanup both headers from unused stuff by Eric's >>> suggestion? >> >> I'm not sure this is a good idea (not that it is bad either). Murphy's >> Law says that a function that you remove today will be used tomorrow. > > I meant literally functions that aren't used in the

> contains most of them. If they're non-trivial (like the ones I needed to > add for OSX functionality) that's a different story. FWIW the difference is even more significant on, e.g. mingw32 because process spawning is pretty much expensive and sometimes configure time dominates the compile time :) -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics,

Okay, i've started slowly working. Who can i send patches for review, when they will be ready? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110106/88a7e893/attachment.html>

> > We may just not use those functions anymore - do you have a list of these? > Yes, i've started to make up a list of those functions, but it haven't finished yet. > This is more concerning - maybe it's a windows specific problem that came > along? > Not sure, i haven't look yet for CMake checking code itself. By the way, i'm using FreeBSD. Or to say it

Ruben Van Boxem <vanboxem.ruben at gmail.com> writes: > And this is why I don't understand configure checks for windows... There's > only one/two header/library sets... The Windows SDK and MinGW. This info > should be built in IMHO... Although the panorama is not so diverse as the Unix world, there is quite a bit of variation on Windows too. Apart from the

On Jan 5, 2011, at 6:34 AM, Óscar Fuentes wrote: > arrowdodger <6yearold at gmail.com> writes: > >>> Or to say it with other words: patches welcome. >> >> So, how should i proceed? Make CMake-generated config to be identical to >> autotools one? > > That would be a good thing. > > Please note that some checks are a bit tricky. A function that

Op 5 jan. 2011 19:33 schreef "Anton Korobeynikov" <anton at korobeynikov.info> het volgende: > > > contains most of them. If they're non-trivial (like the ones I needed to > > add for OSX functionality) that's a different story. > FWIW the difference is even more significant on, e.g. mingw32 because > process spawning is pretty much expensive and

Ruben Van Boxem <vanboxem.ruben at gmail.com> writes: > Yeah that's the two different ones I mean. Everything MS (intrinsics, > language features etc...) is purely version-bound, so I don't even get > why CMake insists on checking every known function prototype of for > example "recv" and for the presence of headers it (or the project > dev!) should know are

On Jan 5, 2011, at 9:58 AM, Óscar Fuentes wrote: > Eric Christopher <echristo at apple.com> writes: > >>>> Or cleanup both headers from unused stuff by Eric's >>>> suggestion? >>> >>> I'm not sure this is a good idea (not that it is bad either). Murphy's >>> Law says that a function that you remove today will be used

2011/1/5 Óscar Fuentes <ofv at wanadoo.es>: > Ruben Van Boxem <vanboxem.ruben at gmail.com> writes: > >> And this is why I don't understand configure checks for windows... There's >> only one/two header/library sets... The Windows SDK and MinGW. This info >> should be built in IMHO... > > Although the panorama is not so diverse as the Unix world,

...thor: David Reveman <davidr@novell.com> Date: Tue Jan 16 06:07:39 2007 +0100 Project vertices and only update minimum required destination texture region. Some more optimizations should be done here but the current changes should still give a major performance improvement. My autofoo is very much lacking so I'm not sure how to add such a check. -- Travis Watkins http://www.realistanew.com

...ather than the need to check for an error return after every call, and internal or usage error will simply mark the working state 'not ready' and the error status may be checked at the end of a block. The libogg calls in-between become safe no-ops. Various build fixes intended to keep the autofoo and Windows build mechanisms up to date. This release is ABI and API compatible with previous incarnations of libogg. Tarballs and zipfiles of the official release can be found in the usual place at http://downloads.xiph.org/releases/ogg/ Happy hacking! Monty xiph.org

Xiph.Org is pleased to announce a full release of libogg 1.2.0. Changes in the new libogg release include: - A new default flushing behavior that reduces overhead for moderate and high bitrate streams, such as video - Documentation updates - Various build fixes intended to keep the autofoo and Windows build mechanisms up to date - Build fixes for additional compilers This release is ABI and API compatible with previous incarnations of libogg. Tarballs and zipfiles of the official release can be found in the usual place at http://downloads.xiph.org/releases/ogg/. Happy hacking!...

...ter for the matrix argument. * Fix 24 bit playback in ALSA plugin * Fix segfaults when closing a driver that did not successfully open. * Fix building Mac OS X driver AUHAL compilation for 10.5 * Fix compilation of sndio plugin Improvements in this release include: * Add autofoo ld symbol versioning to build system * Update Roar driver to latest API * Move toward more consistent option naming across drivers * Add 24 bit playback to Pulse plugin * Restore Mac OS X 10.4 support The libao 1.1.0 release is available from http://downloads.xiph.org/releases/ao/...

I'm tinkering with adding another C program into my fork of icecast. I've installed the libraries on my machine, as well as added both the .c and .h files for the library to my icecast source folder. However, while running make, I get: ad.a httpp/.libs/libicehttpp.a log/.libs/libicelog.a avl/.libs/libiceavl.a timing/.libs/libicetiming.a -lssl -lcrypto -lcurl -lvorbis -logg -lxslt -lxml2