Bugzilla Bug 14148

Hi,

I did ebuilds for DotGNU's Portable .NET
They can be found at http://gentoo-linux.net/ebuilds
Look at bug 12012 - Dan Armak said it's a todo, well, here it is ;)

The ebuilds aren't perfect yet (take a look at BUGS, too ;) but they are a good
basic set for inclusion IMHO....

This also makes QT# and some other things compileable since Portable .NET is
providing cscc, csant and some other things - time to also do a qtc-qtsharp und
qtsharp ebuild ;)

I assigned the bug to foser@gentoo.org since he did the gtk-sharp and mono
ebuild and portable.net/qt# goes the same way...

btw: perhaps it's time to make something like virtual/csharp (if you want to use
mono _or_ portable .net and merge a lib like gtk# or qt# so it isn't "hard
linked" against one of those).

interesting, didnt even know about the project.

The virtual idea is not bad, but it doesnt look like its so easy to use say
another C# compiler for gtk#, mono or any app designed for mcs (comes down to
hacking makefiles etc.).  I tried some stuff, but it looks like dotgnu still
misses a lot of core functionality. There's no use putting it in when it doesnt
work.

I'm not sure how deep you are into it, can you give some advice on
this/pointers/how far it is/etc. ?

The point about the virtual thing is currently a problem because gtk# doesn't
work with pnet without hacking around (since mono and gtk# are working close
together and sometimes changes are made which break gtk# + pnet compatibility)....

You should perhaps really wait a bit before thinking about the virtual thing...

But putting it in isn't a bad idea IMHO since it provides csant (qt# and
kdebindings wants to have it) and the dotgnu stuff alone doesn't have any deps
against other libs etc. so treecc + pnet + pnetlib (+pnetC) could be there
without having infuence on anything else but still provide csant etc.

I don't know wether "there is no use putting it in when it doesn't work" was
meant for the gtk#/qt# thing or for Portable .NET in general but the ebuilds do
work, it's just install-info gives an error because the info files (which are
generated from a .texi - I already told the author to fix it) are missing a
neccessary part, so it is very likely to be fixed with the next release of
treecc and pnet...

I'd suggest putting it in then because no problems are left then (we perhaps
shouldn't care about the virtual thing or making it work with gtk#/qt# yet) -
for now it's just "that it's there" because it provides csant and some other
nice stuff :)

i meant the 'putting it in' stuff for the virtual really, wasn't too clear on
that :)

Anyway on second thought i might as well do it when im adding the ebuilds, mono
will be first choice. Do you know if there's any work been done on supporting
another c# compiler then mcs in for example gtk-sharp makefiles. As it is
gtk-sharp really depends on mono specificly with its mcs oriented makefiles and
hacking makefiles by us is imo not a good option. If i make it virtual it should
at least be transparent for ebuild creators to choose on or the other c#
compiler to use in their ebuils (i'm thinking something along the lines of
gcc-config).

I think it would be quite resource intensive to make it virtual now, right...as
I said gtk# guys seem to prefer working with mono (their mailing list is hosted
at ximian and so on ;)...So the best thing (I think) is to add the ebuilds but
not to touch gtk# and/or mono...The good thing about it is that you can merge
Portable .NET and you have csant and dotgnu's portable .net framework and can do
C# with it - this also gives us the possibility to use qt# (already tried it but
that seems even more complicated)....so my solution would look like this:

Wait for the next release so that the install-info errors are gone
Put treecc, pnet, pnetlib and - optionally but it doesn't hurt if we add it -
pnetC in
Don't touch gtk# (keep "hard link" against mono and don't care about dotgnu _yet_)
Qt# (?) - seems quite complicated to integrate _in a good way_ to me

The good thing about it is we don't hurt mono/gtk# users because we didn't
change anything and additionaly we have the pnet tools and thus csant (..) which
is needed for some other things and after all, this doesn't mean hacking around
in makefiles or spending much time on any other things.

In short: imo the goal for now should be 
1. to put Portable .NET in for having csant (...) plus dotgnu's c# compiler etc.
2. and _not_ to make it work with the other libs (read: not touch anything else
yet since it is already a success if we _have_ Portable .NET - make it work with
the other things follows later ;)

(after irc conversation)

1. waiting for a fixed release of dotgnu before adding to portage
2. postponing virtual/c-sharp until both libs/compilers matured
3. java-config like switch scheme should be implemented after (2)

New release, reopened bug
The ebuilds can be found at gentoo-linux.net/ebuilds

(Note: It was released just a few hours ago, the download link still gives a 404 (mirrored by dotgnu.org and thus all GNU mirrors - the main server in australia is very slow so I didn't change the SRC_URI).

Perhaps it's time to close bug#
14183, 14184. 14185, 14186

Files were uploaded and mirrored some minutes ago, it should work now

*** Bug 14183 has been marked as a duplicate of this bug. ***

*** Bug 14184 has been marked as a duplicate of this bug. ***

*** Bug 14185 has been marked as a duplicate of this bug. ***

*** Bug 14186 has been marked as a duplicate of this bug. ***

I just fine-tuned the ebuilds a bit:
pnet now uses the flag-o-matic eclass for a _much_ nicer filtering of the flags
pnetC ebuild was corrected to lowercase [pnetc-0.5.0.ebuild] (SRC_URI and S had to be customized because of this, just used a new VAR for it to not give static directories).

ebuilds with some minor fixes added. please give it a go.

Just merged them and they work as they should ;)
Thanks for adding them

sorry it took so long ;) closing this and thanks for providing them