Is there a reason why this cannot be done?
DDL for latest source tarball?
|
11-07-2012, 12:58 PM
Yes, nobody wants to take the time to do it and maintain it in the future.
11-07-2012, 03:50 PM
Quote:Because no one would have any reason to trust it. Nobody with two spare brain cells functioning correctly would put the source in that archive into a compiler. That's quite an exaggeration. People can look through the source before compiling, the same as with any other source code. A lot of people are even willing enough to try compiled binaries from third-party sources (Alien's slackbuilds, custom repos, Windows freeware). 11-08-2012, 12:16 AM
(11-07-2012, 12:58 PM)delroth Wrote: Yes, nobody wants to take the time to do it and maintain it in the future.No one wants to take the 30 seconds it would require to archive the latest stable version of your source (with and/or without externals) and upload it to your site so this package can exist, be custom built from source, and used on at least two more OSes (that I can think of)? There is nothing to maintain. Distfiles aren't supposed to change. Once you do this, it's done. You do the same every release. It is absolutely trivial this request. You'd probably even get some free patches out of the deal when the *BSD people build and test it on their platforms. The result is better code, a better product. How does this not work out in your favour? 11-08-2012, 04:56 AM
(11-08-2012, 12:16 AM)pville Wrote:Sorry, I had 30 seconds to spend on that and I already spent that time arguing with you.(11-07-2012, 12:58 PM)delroth Wrote: Yes, nobody wants to take the time to do it and maintain it in the future.No one wants to take the 30 seconds it would require to archive the latest stable version of your source (with and/or without externals) and upload it to your site so this package can exist, be custom built from source, and used on at least two more OSes (that I can think of)? 12-01-2012, 08:55 AM
http://dolphin-emu.googlecode.com/archiv...aa969c.zip
Google Code added a feature to download an archive of any revision. That should do it, right? 03-28-2013, 09:27 PM
(12-01-2012, 08:55 AM)delroth Wrote: http://dolphin-emu.googlecode.com/archiv...aa969c.zipIndeed, my fine emulator friend. I was using this: http://dolphin-emu.googlecode.com/archive/3.5.zip which is huge (and i can't remember how i found that link!), because it seems like you guys bundled externals with it. Here's the output of the fetch, configure, and build stages with that distfile: http://www.sendspace.com/file/a9lik2 and then i saw that you kindly uploaded: https://dolphin-emu.googlecode.com/files....5-src.zip so, i tested that too and the output is here: http://www.sendspace.com/file/y3nv19 There are some problems in the configure stage. As you can see, portaudio, soil, and Cg are installed, but the cmake script doesn't detect them. I haven't had much time on this lately (as you can see from the last post date), but maybe i can have a look at the CMakeLists file and patch it (although i'm not very good at cmake, but have made some patches work before). You can also see that the build fails, even with the -std=c++0x flags passed to the compiler. Any ideas? I'm available for testing this package, as it is very interesting to me. 03-28-2013, 10:11 PM
Your toolchain is too old, your libstdc++ apparently does not define std::mutex. Upgrade your toolchain.
No idea why the cmake script does not detect the libs, maybe wrong pkg-config setup and/or strange installation directories. 03-29-2013, 02:21 AM
We require at least GCC 4.6 to build our project, which is like delroth said. Your toolchain is too old for us.
(03-29-2013, 02:21 AM)Sonicadvance1 Wrote: We require at least GCC 4.6 to build our project, which is like delroth said. Your toolchain is too old for us.Oh, that's no problem. Thanks for that information. I just added GCC_REQD=4.6 to the pkgsrc Makefile for dolphin: # ls -l /usr/pkgsrc/stable/wip/dolphin/work/.gcc/bin/g++ lrwxr-xr-x 1 root wheel 22 Mar 30 12:33 /usr/pkgsrc/stable/wip/dolphin/work/.gcc/bin/g++ -> /usr/pkg/gcc46/bin/g++ and it gets pulled in automagically. It would be good to add that dependency somewhere in your documentation. Still the same error during build though. Regarding the location of SOIL, there's two makefiles that are included with SOIL. One installs the include file, which dolphin's CMakeLists.txt looks for, in ${PREFIX}/include/SOIL, and the other which just installs it into ${PREFIX}/include. When i packaged SOIL (just to test it with dolphin really), i had it just install to ${PREFIX}/include, because 1) it's just one file 2) the other makefile which installs the header into ${PREFIX}/include/SOIL was somehow broken under pkgsrc and i didn't feel like taking the extra time to figure out why. The SOIL library is installed into ${PREFIX}/lib in both cases. Given that there's two options for the SOIL install and we can't assume all OSes/distros/etc. put it in the same place, dolphin's configure stage needs to test for both locations. This can be achieved with this modification to CMakeLists.txt: - check_lib(SOIL SOIL SOIL/SOIL.h QUIET) + check_lib(SOIL SOIL SOIL.h SOIL/SOIL.h QUIET) I'm not sure why the tests for Cg and cgGL are failing, because they're tested for here: Cg/cg.h Cg/cgGL.h and we have them installed here: /usr/pkg/include/Cg/cg.h /usr/pkg/include/Cg/cgGL.h I would imagine the test would have found those easily, but then again, i'm pretty new at hacking cmake. I'll look into the portaudio test when i have a few more minutes. Let me know if you can think of anything else that would make the build continue beyond where it's failing now. It's interesting that you're offering SDL2 as a package option, because there's no stable release of it. I packaged it just to test it with dolphin and 1/3 of the last tarballs they've "released" has built and worked correctly. Which revision of SDL2 are you testing with dolphin? What version of SFML are you using also? The older, stable 1.6 version or the newer, beta 2.0 version? The VBA-M team told me that the API has changed a bit between the versions, so I just want to make sure we're using the same one. I'm assuming that this is also the C++ bindings for SFML. I packaged it originally for use with their project, so nice to see it used somewhere else and getting some more testing. |
« Next Oldest | Next Newest »
|
Users browsing this thread: 2 Guest(s)