Summary: | nant-0.85.ebuild (new eBuild) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Tim Rädisch <tim.raedisch> |
Component: | New packages | Assignee: | dotnet project <dotnet> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | avuton, lars, nuno.araujo, smulloni, tim.raedisch |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
URL: | http://nant.sf.net | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 62055 | ||
Attachments: |
nant-0.85.20040904.ebuild
nant-cvs-20040911.ebuild nant ebuild nant-0.85.2005.03.10.ebuild framework.patch nant-0.85.2005.03.10.ebuild nant-0.85.2005.03.10.ebuild |
Description
Tim Rädisch
2004-09-12 02:27:05 UTC
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. |