Hi, Is is possible to have makefiles, batchfiles, whatever that just calls the command-line compilers and doesn't require this huge amount of per-compiler-version crap? Otherwise, I'm seriously considering removing all those project files from the build since time has proven there's just no way to get them up-to-date. Jean-Marc Alexander Chemeris a ?crit :> Hello, > > On Wed, Oct 1, 2008 at 8:29 PM, Kerry Bonin <kerry at vscape.com> wrote: >> - Anyone else see this? >> - Who maintains the Win32 projects (at least the VS2005)? I'd be happy >> to work with to solve. >> - If nobody is actively maintaining this build, I'd be glad to fix and >> contribute back. > > I'm currently listed as a Win32 build system maintainer, but I prefer not > to take discussions off the list. > In my day-to-day development I use VS2003 and have VS2005 only on > dedicated VM, and I havn't experienced any of these problems. Probably > that's because VM is allowed to use only one core. I'd be glad to work > with you on these problems and I'll ask my co-workers with VS2005 > to test build on real hardware instead of VM. If you have any ideas > or patches to solve this problem - post them here. > >> - On the SVN vs. GIT query above, are these still synched? We use SVN >> for rest of project, so including via svn external is very convenient, >> nice to know if valid... > > I think SVN version is now a little bit outdated. Though build system > has not diverged too much yet. That's very sad Jean-Marc decided > to drop SVN maintenance, it was very handy to use it in large > svn-backed projects. > >> Just wanted to touch base with the list before I burnt time tracking >> down Microsoft issues, in case there are any simpler fixes for this I >> missed in mailing list archives and google... > > I believe you're the first to report these issues. > >
Hi all, On Thu, Oct 2, 2008 at 7:06 AM, Jean-Marc Valin <jean-marc.valin at usherbrooke.ca> wrote:> Is is possible to have makefiles, batchfiles, whatever that just calls > the command-line compilers and doesn't require this huge amount of > per-compiler-version crap? Otherwise, I'm seriously considering removing > all those project files from the build since time has proven there's > just no way to get them up-to-date.It is possible (I think) create a batch file which will compile Speex. If anyone take this - it will be a good solution, probably. I've attached the fix for VS files to include multi-channel changes. It also have a patch for scal.c which adds M_PI define to it. I'm not sure where to define it correctly, so I went with the simplest way. Now git version of speex build correctly on my VS2003. I'll test it with VS2005 shortly. -- Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000 -------------- next part -------------- A non-text attachment was scrubbed... Name: speex-mc-windows-updates.diff Type: text/x-diff Size: 3278 bytes Desc: not available Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20081002/799fced5/attachment.diff
> Is is possible to have makefiles, batchfiles, whatever that just calls > the command-line compilers and doesn't require this huge amount of > per-compiler-version crap? Otherwise, I'm seriously considering removing > all those project files from the build since time has proven there's > just no way to get them up-to-date.It would actually be fine to just maintain the VC2003 (or possibly older) VC project file (and only the project file is needed). All newer VC versions will happily upgrade an older project if you try to open it. That said, we don't use the supplied project. We simply compile in the speex .c files. You could easily replace the Win32 build files with a readme showing which .c files NOT include in your project file. If you'd like, I'd be happy to produce a readme file on how to make a VC project file for speex. Although this approach would require a small amount of effort by each user, it would be resistant to being made obsolete by either new .c files or a new compiler release, and could be maintained by the same person maintaining the autoconf?build system. Cheers, Dave
David Hogan a ?crit :> That said, we don't use the supplied project. We simply compile in > the speex .c files. You could easily replace the Win32 build files > with a readme showing which .c files NOT include in your project > file. > > If you'd like, I'd be happy to produce a readme file on how to make a > VC project file for speex. Although this approach would require a > small amount of effort by each user, it would be resistant to being > made obsolete by either new .c files or a new compiler release, and > could be maintained by the same person maintaining the autoconf build > system.So far, it seems like the most sensible idea I've heard on that topic. It probably wouldn't be hard to have a small script that produces an exact list of files from the autotools files. Another advantage is that those who can't figure out how to create a project from these instructions probably shouldn't be using Speex to begin with :-) Jean-Marc