Bugzilla Bug 63758

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 an attachment (id=39428) [edit]
nant-0.85.20040904.ebuild

ebuild for nightly build packages

Created an attachment (id=39429) [edit]
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 an attachment (id=42590) [edit]
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 an attachment (id=53270) [edit]
nant-0.85.2005.03.10.ebuild

Created an attachment (id=53271) [edit]
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 an attachment (id=53290) [edit]
nant-0.85.2005.03.10.ebuild

I submitted accidentally an old version of the ebuild

Created an attachment (id=53329) [edit]
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.