wx.NET is a set of wxWidget bindings for mono. You can write cross-platform apps that use the native widget set (gtk, windows, OS-X). I need some help from you mono people (latexer?). I've got it to build fine, but I'm not sure where this should go in the filesystem. Create the digest, unpack it then: ebuild wxnet-cvs-20041012.ebuild compile then cd to ${S} and run ./Sample-Launcher.sh to see a demo The files that should be merged to the filesystem are in ${S}/Bin
Created attachment 43879 [details] wxnet-cvs-20041012.ebuild
Created attachment 43880 [details, diff] Defs.in.patch
Created attachment 43909 [details] wxnet-cvs-20041012.ebuild This ebuild seems to install everything fine. Just two dll's and a .so library in /usr/lib.
Is the wxnet-run stuff really needed? I though it's there just to add the .so locations to the LD_LIBRARY_PATH which is now useless when installed to /usr/lib... ...or am I missing something?
Nah, wxnet-run isn't necessary to run apps but the demo launcher uses it, so I just thought it'd be easier to leave it. This new ebuild adds the html docs and makes a link in /usr/bin to towxnet.exe (used to convert wxglade or XRC files to c#)
Created attachment 45185 [details] wxnet-cvs-20041012.ebuild
Hi, I tested you ebuild and it don't work :-( I have put the PORTAGE_OVERLAY directory in my make.conf Put your ebuild in it. And then it show the following error. mastern wxnet-cvs-20041012 # pwd /usr/local/portage/x11-libs/wxnet-cvs-20041012 mastern wxnet-cvs-20041012 # ebuild wxnet-cvs-20041012.ebuild digest !!! aux_get(): ebuild path for 'x11-libs/wxnet-cvs-20041012' not specified: !!! None !!! aux_get(): ebuild path for 'x11-libs/wxnet-cvs-20041012' not specified: !!! None doebuild(): aux_get() error; aborting. mastern x11-libs # emerge wxnet-cvs-20041012 Calculating dependencies !!! Problem in null/wxnet-cvs-20041012 dependencies. !!! "Specific key requires an operator (null/wxnet-cvs-20041012) (try adding an '=')" exceptions Can you help me ?? bye david_
It should be in a directory without the version number: /usr/local/portage/x11-libs/wxnet-cvs not this: /usr/local/portage/x11-libs/wxnet-cvs-20041012
Just in case nobody noticed, 0.6 is out...
I've created ebuild for 0.6.1 version of wx.NET. It uses the original Defs.in.patch and adds another one (wx-config-helper.patch)... All tested and works fine. I've even downloaded the Windows binaries and they work fine, too... I think this ebuild is now ready for portage...
Created attachment 49777 [details] wxnet-0.6.1.ebuild
Created attachment 49778 [details, diff] wx-config-helper.patch
Just a quick repair: the comment shoud say "~/.wapi", not "~/.wabi"...
...shoudn't this be reassigned to dotnet herd, btw...?
Perhaps you can help me: I got the following error. I suppose my wxGTK is not well configured. Could you please tell me with which USE-flags you compiled it? html.cxx html.cxx: In function `void wxHtmlEasyPrinting_PrinterSetup(wxHtmlEasyPrinting*)': html.cxx:1919: Fehler:
Perhaps you can help me: I got the following error. I suppose my wxGTK is not well configured. Could you please tell me with which USE-flags you compiled it? html.cxx html.cxx: In function `void wxHtmlEasyPrinting_PrinterSetup(wxHtmlEasyPrinting*)': html.cxx:1919: Fehler: »class wxHtmlEasyPrinting« hat kein Element namens »PrinterSetup« make[2]: *** [obj/html.o] Fehler 1 make[1]: *** [wx-c] Fehler 2 make[1]: Leaving directory `/var/tmp/portage/wxnet-0.6.1/work/wx.NET-0.6.1' make: *** [wxnet-core] Fehler 2 !!! ERROR: dev-dotnet/wxnet-0.6.1 failed. !!! Function src_compile, Line 57, Exitcode 2 !!! make wxnet failed !!! If you need support, post the topmost build error, NOT this status message.
Ok, it was my fault. I installed wxGTK-2.5.4, which seems to be not compatible with wx.NET 0.6.1. Tim
There is a dup of this bug, #87869 which I won't have time to test until I get wxGTK-2.6.0 in portage later this week.
*** Bug 87869 has been marked as a duplicate of this bug. ***
FYI, wx.NET 0.6.1 needs further patching before running with wxGTK 2.6.0. I haven't verified this myself, but apparently the Mdi and Dialogs samples break with 2.6.0. Changes are in wx.NET cvs. If I get a chance, I'll try to find the patch and test it. Reference: http://article.gmane.org/gmane.comp.lib.wxwindows.wxnet/636
(dotnet herd piping in just to comment on the few things) 1) To fix the WAPI stuff, please just inherit from the mono eclass. that will solve all those issues for you. 2) .dll and .exe files should never go into /usr/lib or /usr/bin/. All those should go into a subdirectory of /usr/lib, like /usr/lib/wxnet/ and only wrapper scripts for executing the .exe files with mono should go into /usr/bin/ Most of the other issues are up to the wxwindows herd to sort out.
My ebuild <a http://bugs.gentoo.org/show_bug.cgi?id=87869>Bug 87869</a> conforms to this (inherits from mono eclass, no .exe in /usr/bin. I used a slightly different naming convention, but that can be easily fixed). I hope someone takes a look before it gets forgotten.
Created attachment 57952 [details, diff] patch from upstream fixing problems with wxGTK-2.6.0 Patches from wx.NET CVS fixing problems with wx.NET 0.6.1 and wxGTK-2.6.0. Everything builds fine for me, and wx.NET samples run as well as they did with wxGTK-2.5.3 (everything runs, but there are a few bugs here and there). Note: Unpatched wx.NET was not tested against wxGTK-2.6.0 and patched wx.NET not tested for compatability with wxGTK-2.5.3.
Thanks Terry, its not forgotten. 2.5 was too much of a moving target to put in stable portage so I've just been waiting for 2.6. I'll test out your changes today. Definately don't worry about making it work with wxGTK-2.5*, they aren't ever leaving package.mask. Thanks for clearing that up Peter (comment #20), and if you want dotnet herd to maintain this after I make sure the wx stuff is working right, be my guest. :D
...as for the GAC topic: It indeed should be installed to GAC (not /usr/lib) but please don't forget there's also pnet so installing into mono's GAC will make it unusable from pnet... :-( Anyway, has anyone been playing with the 2.6 compatibility? I'm still unable to compile it. If anyone has a working ebuild, please post it... Thanks...
Radek, Quick and dirty way to get wx.NET compiled and installed against wxGTK 2.6 would be to pop over to Bug 87869, grab the ebuild you find there and all the patches. In addition, grab my 2.6 compatability patch from here (the last one in the attachments table as I type this - dated 2005-05-03). Update RDEPEND to require wxGTK-2.6.0 and add the following to to include this last patch: epatch "${FILESDIR}/wxGTK-2.6.0-compat.patch" It should compile - this is what is sitting on my system at the moment. I've been meaning to look through the ebuild and patches in this bug listing and merge in my stuff to make a new ebuild, but haven't had a chance yet. Not likely real soon as I'm busy with other stuff. I'm not sure what the best solution is with regards to packages that are compatible with both mono and pnet - clearly this is a higher order issue that falls within the purview of the dotnet herd. Does pnet even have a GAC or strong naming yet? (Sorry, I'm not familiar with it). A standard install clause that does the right thing depending on USE flags might be enough.
...yeah, my fault. Forgot to modify something in the ebuild. Never mind...
Some minutes ago I want to emerge the wxnet-0.6.1 ebuild. It doesn't work. Dependency >=dev-dotnet/mono .. couldn't satisfy, because mono-1.xxx is in dev-lang (in the current portage-tree).
The 0.7.1 version has been out for quite some time. I've created an ebuild (mostly the same as the 0.6.1 version) but I'm still getting some compile-time errors. I'll post the ebuild ASAP.
Hmmm, I can't explain this, but after recompiling wxGTK several times (for testing something else) my ebuild started to work without modifications. Attaching it, please add to portage...
Created attachment 64047 [details] wxnet-0.7.1.ebuild
Created attachment 64048 [details, diff] Defs.in.patch for 0.7.1
I've created and ebuild for the latest 0.7.2. It's going to be the only version for some time so please, add this to portage... Thanks... Radek
Created attachment 64380 [details] wxnet-0.7.2.ebuild
Created attachment 64381 [details, diff] Defs.in.patch for 0.7.2
...ummm, I don't want to be rude but is there a reason why this is not in portage? I think it's ready for some time now and nobody complained...
...I've just installed this on a new, independent and freshly-installed machine and it works out of the box. This IS ready for portage...
Another successful install. Come on! This bug is more than a YEAR OLD!
I agree with Radek. Let's get this into portage or at least hear an explanation of why not. If there are any unspoken outstanding issues or problems which are holding this up, let's get them out in the open so they can be addressed.
QA review of the ebuild in attachment #64380 [details] as requested by Grant: * We don't use the gtk2 flag any more except in ebuilds that haven't been converted over yet. * DEPEND on sed is unnecessary. * Is there really no build dependency upon gtk or mono? * epatch calls die for you * dodir in src_compile? Not a good idea. * The need-wx stuff should probably be in pkg_setup * The ebuild will die if use !unicode && use !gtk2. This is a policy violation. * make not emake? If this is really necessary, comment it
I'm not sure why this ebuild is languishing, other than I suspect that it fell through the cracks after being assigned. CC'ing the dotnet folks to see if they are willing to take this ebuild.
Grant asked me to comment, here's what I told him on IRC. </snip> 08:09 <@latexer> we're not willing, because dotnet herd mostly == me. 08:10 <@latexer> and i don't have the time to maintain a large package i don't use and can't really test. </snip> I've got enough on my hands with the current packages the dotnet herd maintains. Someone else is going to have to step up to be the maintainer of this, if they actively use some package that uses it, or whatever. Sorry.
Hmmm. Sounds like the dotnet herd needs a few more hands. I'm willing to step up and contribute. Where do I sign up?
The mono depend should be removed as well because we also have pnet...
One more thing, there is a binary version of premake included which of course fails to run on other platforms than x86. So I've created an ebuild for premake (bug 123366)that we should depend on (and fix the makefile in wx.NET which has the Build/Linux/premake path hardcoded)...
Created attachment 80164 [details] wxnet-0.7.2.ebuild Hopefully corrected stuff mentioned it comment #39. Note this does not work yet (I'm having some not related trouble) but is a good starting point for anyone else who want to finish this...
(In reply to comment #43) > The mono depend should be removed as well because we also have pnet... > Do you mean perhaps mean exclusive dependency on mono, so the ebuild depends on either mono or pnet? I can't see removing mono depend just because pnet also exists.
Created attachment 80166 [details] premake.patch
Created attachment 80167 [details] premake.lua.patch
Created attachment 80168 [details] wxnet-0.7.2.ebuild Sorry for so many posts. This is as far as I can go. I'm getting premake segfaults on amd64 (but it's no premake specific, I get them elswhere, too) so can someone please test the latest ebuild and give me some feedback? Thanks...
(In reply to comment #46) > (In reply to comment #43) > > The mono depend should be removed as well because we also have pnet... > > > > Do you mean perhaps mean exclusive dependency on mono, so the ebuild depends on > either mono or pnet? I can't see removing mono depend just because pnet also > exists. > Yeah, I meant something like this or see bug 123362 for more generic solution (I asked gentoo devs to add something like virtual/dotnet).
(In reply to comment #49) > Created an attachment (id=80168) [edit] > wxnet-0.7.2.ebuild > > Sorry for so many posts. This is as far as I can go. I'm getting premake > segfaults on amd64 (but it's no premake specific, I get them elswhere, too) so > can someone please test the latest ebuild and give me some feedback? Thanks... > Am busy with other stuff at the moment, but didn't want to let this slip by: See also comment #20 and comment #21. This ebuild doesn't conform to point #2. My old ebuild can be used as a guide (I think - haven't looked at it in some time).
(In reply to comment #51) > (In reply to comment #49) > > Created an attachment (id=80168) [edit] > > wxnet-0.7.2.ebuild > > > > Sorry for so many posts. This is as far as I can go. I'm getting premake > > segfaults on amd64 (but it's no premake specific, I get them elswhere, too) so > > can someone please test the latest ebuild and give me some feedback? Thanks... > > > > Am busy with other stuff at the moment, but didn't want to let this slip by: > > See also comment #20 and comment #21. This ebuild doesn't conform to point #2. > My old ebuild can be used as a guide (I think - haven't looked at it in some > time). > Well, AFAIK there's still no real policy here so I'll wait for the dotnet guys to make up their minds (install to /usr/lib or /usr/lib/something or mono GAC or whatever). Feel free to modify the ebuild...
Created attachment 80174 [details, diff] premake.lua.patch
Created attachment 80207 [details] wxnet-0.7.2.ebuild So this is my final ebuild. I've been fighting it all day and I finally got it to build under amd64. It depends on premake-2.4 (see other bugs) so the premake.lua.patch isn't really needed, it's there for the premake 3.x series (which are giving segfaults on amd64)... Can someone please revise the ebuild and finally add it to portage? Thanks...
Created attachment 80208 [details] fpic.patch Needed for successful linking on amd64.
Terry: find open enhancement bugs with no ebuilds and contribute them, or find open .NET bugs (basically anything assigned or CCed to dotnet@gentoo.org) and submit fixes for the problems. If you start showing consistent good work, then one can start considering coming on as a dev. Radek/all: Concerning where to *put* the libs, the GAC should only be used for libs that have API stability guarantees. If that is not the case for this, then /usr/share/${PN}/ is a good spot to place the libs if they have no C glue, or /usr/$(get_libdir)/${PN} if they have C glue bits. Programs wishing to use the libs should then compile then into the dir next to the apps. Concerning the pnet/mono stuff, if wx.NET is designed to build/work with both, then probably this should follow something like USE="mono" DEPEND=" mono? ( dev-lang/mono ) !mono? ( dev-lang/pnet )" And then use the same USE flag logic to determine if it should do the pnet or mono building.
Radek: I can take care of this as soon as you follow Peter's advice (mono USE flag). Moreover it would be better if you changed the 'samples' USE flag to the well-known 'examples' USE flag. Also consider adding multilib support if you add stuff to /usr/lib.
Created attachment 141145 [details] wxnet-0.7.2.ebuild
Created attachment 141147 [details, diff] premake.lua.patch
I've replaced all premake.lua files with the versions coming along the new 0.8.0 release. I haven't update the ebuild (but it should be trivial) because i need that specific version of wxnet. It strarts compiling fine but it finally give up on the linking : Linking wx-c /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lwx_gtk2u_xrc-2.6 collect2: ld returned 1 exit status make[1]: *** [../../Bin/libwx-c.so] Error 1 make: *** [wx-c] Error 2 Although that library is present in my /usr/lib folder If someone has any idea...
Forgive my potential ignorance here but the ebuild posted for 0.7.2 depends on dev-util/premake which is no longer in portage. I have written an ebuild for the latest version of premake with the hopes that it can be added back into the tree. So shouldn't this bug depend on bug #60960?
(this is an automated message based on filtering criteria that matched this bug) 'EBUILD' is in the KEYWORDS which should mean that there is a ebuild attached to this bug. This bug is assigned to maintainer-wanted which means that it is not in the main tree. Hello, The Gentoo Team would like to firstly thank you for your ebuild submission. We also apologize for not being able to accommodate you in a timely manner. There are simply too many new packages. Allow me to use this opportunity to introduce you to Gentoo Sunrise. The sunrise overlay[1] is a overlay for Gentoo which we allow trusted users to commit to and all users can have ebuilds reviewed by Gentoo devs for entry into the overlay. So, the sunrise team is suggesting that you look into this and submit your ebuild to the overlay where even *you* can commit to. =) Because this is a mass message, we are also asking you to be patient with us. We anticipate a large number of requests in a short time. Thanks, On behalf of the Gentoo Sunrise Team, Jeremy. [1]: http://www.gentoo.org/proj/en/sunrise/ [2]: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq
