Hi,
I would like to package Dolphin for pkgsrc. In theory, if it builds under pkgsrc, it would build on 15 or so OSes across many, many architectures. However, I could not find a direct download link to the latest release source tarball. That would be necessary to package Dolphin. Would it be possible to provide a tarball/zip file/whatever archive you use where your code is hosted? Right now, there are just the binaries for Mac OS X and Win32/64.
Best regards,
We don't have a source tarball, but we have a git repository:
http://code.google.com/p/dolphin-emu/source/checkout
Dolphin uses quite a bit of x86/64 assembly for its JIT cores; you wouldn't be able to compile it for anything else unless you've got some crazy conversion contraption in pkgsrc. Nanimo/Sonicadvance1 is working on porting everything to ARM, though.
Make sure to look at the wiki pages on the Google Code page for more info on what Dolphin requires.
(09-22-2012, 12:20 AM)pville Wrote: [ -> ]There is no DDL on that page. Can we have a 3.0 source tarball/zip file listed on the downloads page?
(09-21-2012, 11:16 PM)pauldacheez Wrote: [ -> ]We don't have a source tarball, but we have a git repository
pauldacheez pretty much answered your question. There are no tarballs/zip files of the source code atm. You need to make a git clone of the repository, then checkout the hash for 3.0. This is how you do it on Linux, should be close enough if not the same for BSD:
Code:
git clone https://code.google.com/p/dolphin-emu/ dolphin-emu
cd dolphin-emu
git checkout 35d1599724a4
I know there are no source distfiles. That was the entire point of this thread. I'm asking if we could have one. It doesn't seem to be a difficult request to fill. We need to run checksums against one distfile; not download an entire directory and run consistency checks on it based on another file that is also fetched remotely.
If Dolphin only currently supports the i386 and amd64 platforms, then it will just build the package on them. When ARM support is added, it will automatically be supported under pkgsrc (as various ARM ports are supported by it). That is the magic of pkgsrc. It is also a very effective means of testing this package across multiple OSes and could provide valuable feedback to your developers.
Now about that distfile...
(09-22-2012, 02:49 AM)pville Wrote: [ -> ]I know there are no source distfiles. That was the entire point of this thread. I'm asking if we could have one. It doesn't seem to be a difficult request to fill. We need to run checksums against one distfile; not download an entire directory and run consistency checks on it based on another file that is also fetched remotely.
If Dolphin only currently supports the i386 and amd64 platforms, then it will just build the package on them. When ARM support is added, it will automatically be supported under pkgsrc (as various ARM ports are supported by it). That is the magic of pkgsrc. It is also a very effective means of testing this package across multiple OSes and could provide valuable feedback to your developers.
Now about that distfile...
Not a distfile, but here ya go:
Full repository up to 3.0-772-g8fed3b7
Archived in
7-zip format. you will need latest version to extract it.
While I do appreciate the posted distfile, it's 1) still not a DDL 2) not from the official Dolphin site or one of its official mirrors. We couldn't include that distfile for pkgsrc. A DDL looks like this:
http://dolphin-emu.googlecode.com/files/dolphin-3.0-src.7z
It is a Direct Download Link. Emphasis on the direct part, as in there are no redirects. If you look closely, you can see that it also comes from the official Dolphin code host.
We don't provide source packages because a) no one of the devs really care about it (sorry, but it's the way it is) b) the source is >50 MB when including the Externals directory (if we excluded that, we'd basically drop Windows support for the source package AND most linux distributions which don't have all of the dependencies in their default repos) c) I don't really see why you can't just use Git for getting the source (Git doesn't require you to check out the whole history [I think you can even get around creating a local Git repo at all?], so you really get the same result like with a tar.gz anyway).
(09-27-2012, 02:54 AM)neobrain Wrote: [ -> ]We don't provide source packages because a) no one of the devs really care about it (sorry, but it's the way it is) b) the source is >50 MB when including the Externals directory (if we excluded that, we'd basically drop Windows support for the source package AND most linux distributions which don't have all of the dependencies in their default repos) c) I don't really see why you can't just use Git for getting the source (Git doesn't require you to check out the whole history [I think you can even get around creating a local Git repo at all?], so you really get the same result like with a tar.gz anyway).
a) If you don't care, then I can't care for you. This is an opportunity to see how Dolphin compiles across many different systems and also to bring the joy of GameCube/Wii gaming to more people. The pkgsrc team has a set of servers which are used to bulk build packages and test them. You can see some examples of pkgsrc bulk build results here:
http://mail-index.netbsd.org/pkgsrc-bulk
If that's not interesting to any of your developers...
b) Make two source distfiles available on you code host every time you do a stable release - one which includes the externals and one which doesn't. Simple. Other OSS packages also provide such a set of distfiles. I would be interested in the one without the externals, as the pkgsrc framework would automatically fetch, build, and install Dolphin's dependencies. Given that you don't do stable version releases that often, a generation of said distfiles is trivial.
c) Fetching one distfile and running a consistency check against it and fetching $x individual files and not having a consistency check for them is not the same result. You're seeing the unpacked distfile already and saying it's the same as checking out the repository. I'm saying that the process to get to the result is important and, in this case, not the same.