It's not that hard to repackage it, is it?
Here you go: www.icer.nl/misc_stuff/flac.xcodeproj .zip
On 06-05-13 23:37, Marcus Johnson wrote:> Ralph, for Mac OS you should download either the Unarchiver which is
> free, or Entrophy which is what I use, but it costs like $15 I
> believe, both support decompressing .7z and Entrophy supports
> compressing TO .7z
>
>
> On Mon, May 6, 2013 at 3:00 PM, <flac-dev-request at xiph.org
> <mailto:flac-dev-request at xiph.org>> wrote:
>
> Send flac-dev mailing list submissions to
> flac-dev at xiph.org <mailto:flac-dev at xiph.org>
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.xiph.org/mailman/listinfo/flac-dev
> or, via email, send a message with subject or body 'help' to
> flac-dev-request at xiph.org <mailto:flac-dev-request at
xiph.org>
>
> You can reach the person managing the list at
> flac-dev-owner at xiph.org <mailto:flac-dev-owner at xiph.org>
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of flac-dev digest..."
>
> Today's Topics:
>
> 1. Re: Bug fix and compatibility patches for 1.3.0pre4
> (Timothy B. Terriberry)
> 2. Re: Bug fix and compatibility patches for 1.3.0pre4
> (Robert Kausch)
> 3. Re: Bug fix and compatibility patches for 1.3.0pre4
> (Robert Kausch)
> 4. Re: Bug fix and compatibility patches for 1.3.0pre4
> (Robert Kausch)
> 5. Re: Bug fix and compatibility patches for 1.3.0pre4
> (Timothy B. Terriberry)
> 6. Re: Bug fix and compatibility patches for 1.3.0pre4
> (Janne Hyv?rinen)
> 7. Re: (no subject) (Ralph Giles)
>
>
> ---------- Forwarded message ----------
> From: "Timothy B. Terriberry" <tterribe at xiph.org
> <mailto:tterribe at xiph.org>>
> To: flac-dev at xiph.org <mailto:flac-dev at xiph.org>
> Cc:
> Date: Sun, 05 May 2013 14:43:46 -0700
> Subject: Re: [flac-dev] Bug fix and compatibility patches for
> 1.3.0pre4
> Janne Hyv?rinen wrote:
>
> You people do realize these hacks would only be required for
> 10+ year
> old obsolete compilers?
>
>
> No, they're required for easy distribution on 12 year old OSes
> (which, last I saw, make up almost 40% of Firefox's desktop
> userbase, and likely will continue to for some time).
>
>
>
> ---------- Forwarded message ----------
> From: Robert Kausch <robert.kausch at freac.org
> <mailto:robert.kausch at freac.org>>
> To: flac-dev at xiph.org <mailto:flac-dev at xiph.org>
> Cc:
> Date: Mon, 06 May 2013 01:20:52 +0200
> Subject: Re: [flac-dev] Bug fix and compatibility patches for
> 1.3.0pre4
> Timothy B. Terriberry wrote:
>
> _lseeki64 operates on the underlying file handle, and does not
> interact
> well with the buffering in stdio streams. I _think_ you can
> use this
> successfully if you call fflush() beforehand (as this sets
> FILE::_cnt to
> 0 and FILE::_ptr to FILE::_base). By which I mean I read the
> MSVCRT
> source from MSVC6.0 and it appears this is how things work.
>
> Ok, I didn't take that into account. Thanks for pointing it out!
> Using fflush to clear the buffers before calling _lseeki64 sounds
> reasonable, so I think I'll try that.
>
> I noticed another problem with _lseeki64 though. It returns the
> new file pointer position on success instead of 0, so the macro
> will have to take that into account.
>
> That source also includes an fseeki64()/ftelli64(), but they
> are not
> defined in stdio.h. I wonder if just declaring it yourself is good
> enough?
>
> Those functions are not exported by XPs msvcrt.dll, so declaring
> them won't help.
>
>
>
> ---------- Forwarded message ----------
> From: Robert Kausch <robert.kausch at freac.org
> <mailto:robert.kausch at freac.org>>
> To: flac-dev at xiph.org <mailto:flac-dev at xiph.org>
> Cc:
> Date: Mon, 06 May 2013 01:21:56 +0200
> Subject: Re: [flac-dev] Bug fix and compatibility patches for
> 1.3.0pre4
> JonY wrote:
>
> How about just forgetting about base XP and require at least
> SP2 or some
> such? Alternatively, use win32api underneath instead, eg
> CreateFileW/SetFilePointer.
>
> Even SP2 and SP3 do not have fseeki64/ftelli64. Using Windows API
> functions would probably be the cleanest solution, but on the
> other hand require wrappers for all file IO functions. I guess
> that would be too big of a change to make it into 1.3.0 at this point.
>
>
>
> ---------- Forwarded message ----------
> From: Robert Kausch <robert.kausch at freac.org
> <mailto:robert.kausch at freac.org>>
> To: flac-dev at xiph.org <mailto:flac-dev at xiph.org>
> Cc:
> Date: Mon, 06 May 2013 01:26:08 +0200
> Subject: Re: [flac-dev] Bug fix and compatibility patches for
> 1.3.0pre4
> Timothy B. Terriberry wrote:
>
> Instead I've attached a patch that uses fgetpos/fsetpos. This
> is totally untested (I haven't even checked it compiles), but
> the idea should work.
>
> MSDN says "The pos value is stored in an internal format and is
> intended for use only by *fgetpos* and *fsetpos*."
> (http://msdn.microsoft.com/en-us/library/70hdhh4t%28v=vs.80%29.aspx),
> so I don't think it's a good idea to use it this way even if
tests
> suggested it works.
>
> I'll write a test program tomorrow to try the fflush+_lseeki64
> approach.
>
> Another solution - although a bit ugly - might be to disable
> buffering on Windows using setvbuf.
>
>
>
> ---------- Forwarded message ----------
> From: "Timothy B. Terriberry" <tterribe at xiph.org
> <mailto:tterribe at xiph.org>>
> To: flac-dev at xiph.org <mailto:flac-dev at xiph.org>
> Cc:
> Date: Sun, 05 May 2013 16:34:04 -0700
> Subject: Re: [flac-dev] Bug fix and compatibility patches for
> 1.3.0pre4
> Robert Kausch wrote:
>
> MSDN says "The pos value is stored in an internal format and
> is intended
> for use only by *fgetpos* and *fsetpos*."
>
(http://msdn.microsoft.com/en-us/library/70hdhh4t%28v=vs.80%29.aspx),
> so
> I don't think it's a good idea to use it this way even if
tests
> suggested it works.
>
>
> FWIW, I verified that this is the approach used by mingw32 to
> implement fseeko/ftello.
>
>
>
> ---------- Forwarded message ----------
> From: "Janne Hyv?rinen" <cse at sci.fi <mailto:cse at
sci.fi>>
> To: flac-dev at xiph.org <mailto:flac-dev at xiph.org>
> Cc:
> Date: Mon, 06 May 2013 07:42:34 +0300
> Subject: Re: [flac-dev] Bug fix and compatibility patches for
> 1.3.0pre4
> On 6.5.2013 0:43, Timothy B. Terriberry wrote:
>
> Janne Hyv?rinen wrote:
>
> You people do realize these hacks would only be required
> for 10+ year
> old obsolete compilers?
>
> No, they're required for easy distribution on 12 year old OSes
> (which,
> last I saw, make up almost 40% of Firefox's desktop userbase,
> and likely
> will continue to for some time).
>
>
> What kind of nonsense is this? You should know that the last
> Microsoft compiler to create dynamically linked code that used
> msvcrt.dll was Visual Studio 6.0 from 1998.
>
> Oldest Visual Studio supported by FLAC 1.3 is Visual Studio 2005.
> FLAC is also configured to be compiled with static linking, so no
> external dependencies hinder its function.
>
> If you take a look at the following MSDN pages for Visual Studio
> 2005, you will see that _fseeki64 and _ftelli64 are supported all
> the way back to Windows 95:
> http://msdn.microsoft.com/en-us/library/75yw9bf3%28v=vs.80%29.aspx and
> http://msdn.microsoft.com/en-US/library/0ys3hc0b%28v=vs.80%29.aspx
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Ralph Giles <giles at thaumas.net <mailto:giles at
thaumas.net>>
> To: flac-dev at xiph.org <mailto:flac-dev at xiph.org>
> Cc:
> Date: Mon, 06 May 2013 11:20:15 -0700
> Subject: Re: [flac-dev] (no subject)
> On 13-05-02 7:37 PM, Marcus Johnson wrote:
> > Here's the Flac.xcodeproj, compressed with 7-zip as it's
just a
> folder
> > and can't be transmitted without being compressed, check to
see
> if it
> > works on your computers, and hopefully everything works.
>
> .7z isn't a normal MacOS tool. Could you please send a tar.gz or
.zip
> instead?
>
> -r
>
>
>
> _______________________________________________
> flac-dev mailing list
> flac-dev at xiph.org <mailto:flac-dev at xiph.org>
> http://lists.xiph.org/mailman/listinfo/flac-dev
>
>
>
>
> _______________________________________________
> flac-dev mailing list
> flac-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/flac-dev/attachments/20130507/72ba1844/attachment-0001.htm