This are two ebuilds for NAnt; a .NET tool simmilar to Ant. The ebuilds are in principal identical; the one gets the source from a nightly build and the other from cvs. The main reason why I use myself the CVS version is, because there are currently no nightly builds available (don't know why) and the 0.84 version does not work correct. I suggest dev-dotnet inside portage. Greetings Tim
Created attachment 39428 [details] nant-0.85.20040904.ebuild ebuild for nightly build packages
Created attachment 39429 [details] nant-cvs-20040911.ebuild ebuild for cvs build
Hey, Just a couple things, There seems to be newer stuff here: http://nant.sourceforge.net/nightly/builds/ Unfortunately, it's named *horribly* so you'd either need to make this RESTRICT="nofetch" or let one of us make a custom tarball based on a given nightly build. This would also make the logic of the ebuild nicer/cleaner, although it means slightly more work on the maintenance side of things for us. Concerning the first ebuild you attached: 1) Check out the mono eclass. Inheriting from that solves the nasty ~/.wapi stuff. 2) Why are you exporting those couple other variables? 3) Is creating your own /usr/bin/nant really needed? (i've not had time to look at the particulars. That's just a couple things from me, until i find more time to look into the particulars of this package/ebuild.
Hi! I can take a look at the new builds today, i hope. Creating an own /usr/bin/nant is the easiest way. The other solution is to patch the Makefile so it generates the right script. The "problem" is that the Makefile builds the paths with the ${DESTDIR}-prefix; e.g. /usr/bin/nant will than try to execute a /var/tmp/portage/nant-xxxx/temp/usr/share/NAnt/bin/NAnt.exe. Trying eclass mono sounds good :) Tim Exporting these variables is to a hide a downward compatibiliy messages. In the early times of mono handling of strong names was different to now. But because compatibility you can still use the "old way binaries" but that throws a warning, which I hide. http://www.go-mono.com/remap.html
Em, one stupid question: how can i unzip the nightliy builds? I can extract all files, but the names and paths are concatenated to a new filename. Tim
Created attachment 42590 [details] nant ebuild Okay, here's the latest nant ebuild that i've been working on. Needed to repackage the nant source, as there would be name collisions on the mirrors. Notice the fix for the duplicate building by removing the doc= part of the build stuff. This is needed as mcs doesn't yet have the /doc option. Not a perfect ebuild yet, I need to just test and confirm a few more things before I'm ready to commit this.
Whats the status on getting this into portage, because so many other builds depend on this tool.
0.85rc1 is out, and i have an ebuild pretty much working. I'll hopefully be commiting it soon.
Created attachment 53270 [details] nant-0.85.2005.03.10.ebuild
Created attachment 53271 [details, diff] framework.patch
After a long break I present a working (I hope so) eBuild for NAnt. I have three little problems with it: 1) during "install" it needs write access to /root/.config 2) during "install" the documentation is generated with ndoc, and this needs much more time than the compile process; I'll try to move this to "compile" 3) the documentatin is currently located at /usr/share/NAnt/doc; I could fix this with a simple 'mv', but I'll try to find a adequate parameter Tim
Created attachment 53290 [details] nant-0.85.2005.03.10.ebuild I submitted accidentally an old version of the ebuild
Created attachment 53329 [details] nant-0.85.2005.03.10.ebuild
Ok, i've just commited an ebuild for 0.85-rc2 to portage (one i wrote independantly of this bug). We can't use snapshot sources directly from the nant folks, since they are unversioned, and we'll get source collisions on our mirrors once we have more than one snapshot date in portage. If there are significant changes in snapshots that make it needed over the latest RC, we can rebundle the sources into a versioned tarball and do that. That's a lot more work though, so until then I'm hoping to stick with this. I've included a variant of Tim's framework.patch, as well as another small fix which was needed to fix detection of is-unix() on mono-1.1.x. Please everyone test the version in portage. Pending a few successful reports, i'll mark this FIXED. Thanks everyone.
It works fine for me. And could you add the ~amd64-flag, because it is working there too :)
Ok, marking FIXED. Thanks all for the feedback. Tim: re the ~amd64 keyword, we really can't do that until amd64 has a working mono binary (JIT). That means mono-1.1.4, which is still in package.mask. Once that package.mask is gone (waiting on a new monodevelop which actually works with mono-1.1.x) then we can start realistically adding ~amd64 keywords to this and things like gtk-sharp, etc.
