On Sat, Jun 23, 2007 at 12:25:42AM -0500, Drew Scott Daniels wrote: > ReactOS is different though. They don't try to cross compile Linux > libraries (well maybe some). They use MS Windows like libraries. MFC, > win32, msvcr... quite a bit of the user space code they use is from the > wine project. These libraries provide quite a bit of functionality, > likely duplicating a good portion (if not all of) some of the libraries > you're porting.
Are you sure? Even if it did - wouldn't it be more sensible to write software that uses a cross-platform library like "libpng" than some "natively" available PNG support? The libraries I'm porting are not "unix libraries", they are cross platform libraries, often better suited for their task than any OS specific library. Compare e.g. writing a 2D game with libSDL and DirectX. Writing it with libSDL ist easier, more fun and you get portability. Same for libcURL, GD, etc. > That said, these are targeted at a different audience, > and their project doesn't need many of the apps/libraries that many > Linux developers want. [...] > ReactOS may be interested in a subset of your script. They don't pull in > very many build dependencies. Don't hesitate to start a fork, maybe reusing the general structure of the script, throwing out all libraries you don't need, and put in the libs you want. Those new libs, in turn, I could add to my script. I'm currently even doing it myself! For development purposes, I have a smaller variant of the script that contains all new libraries I'm trying to get working. This new script unpacks the mingw_cross_env.tar.gz (created by the original script) to have a clean startup. Then it builds the experimental libs. This way I can test and fix new build instructions relatively quickly before I put them into the big script and run a final test. > > However, it's sometimes hard to force one package to use the static > > instead of the dynamic variant of a library. Such mistakes are subtle > > and sometimes very hard to find. > > > Any examples? I haven't tried. Just try, you will be "forced" to make that experience. Compile e.g. libpng statically and as DLL. Then compile an application that uses libpng. It will automatically use the DLL variant, and you'll have to do some tweaks to force it to statically link to libpng. The easiest way, by far, is not to build libpng.dll in the first place. :-) Now a more subtle example: LibGD is a generic graphics library that internally uses libpng, libjpeg, etc. It's kind of common API to those libs. Now suppose you build libpng as DLL and static. Same with LibGD. Now you build your app which will then need the libgd.dll. Suppose you don't like that, so you make some tweaks and you link libGD statically into you app. Boing! Your app will still depend on libpng.dll, because even the static libGD variant has been dynamically linked to libpng. I hope, those simple examples make things clear. Now imagine the fun of doing that with 10 libraries. You should consequently use either many small DLLs or one big DLL (or one big EXE). Mixing up is not a good idea. You should make that decision at the beginning, just to decide which library to build as static *.a and which as DLL. If you do this consequently from the beginning, you'll have muss less trouble. > > Is there? Even when you want backwards compatibility to Win98, WinME, > > etc.? > Well, it was a concern for those OS's but not as easy to deal with. [...] > Additionally one can sometimes use dependency walker to > manually find dependencies. Some other examples are OpenOffice.org and > JRE, Games with DirectX, wireshark and winpcap, .Net applications & the > .Net API (though I've learned this can easily be mishandled). That's an interesting point: If you don't need to support older Windows versions, and want a good dependency / DLL handling, why don't you just use .NET? .NET is especially interesting in concerns of portability, because you can use Mono, develop with Mono on Linux, and "porting" to Win32 consists of just copying the *.exe file over. Well, you may also need some Mono-DLLs, but those you can freely distribute with your app. The only bad thing with Mono/.NET is the GUI library "WinForms". However, GTK has been ported to Mono (called GTK#), so you just add some more DLLs and get a good GUI library. So Mono is a very interesting option for win32 cross compiling, if you are starting a new project and don't want to support older Windows versions. > > However, I'm not sure whether it's a good way to build binary packages > > for a "win32" architecture an then convert them via dpkg-cross. > > > I suppose native compilation would be a better approach for win32. For projects like ReactOS: Yes. For single applications that want to provide a Win32 version: No. On Debian we have a MinGW cross compiler, NSIS and UPX. If you add the cross compiled libraries, you everything you need to produce a win32 installer .exe entirely from your Linux system. And in fact, I've already done that for some projects. Tower Toppler (http://toppler.sf.net/) is a good example. > > It would be different if one would just need some simple compatibility- > > patches to the debian/rules. It would be different if the created > > win32-arch-binaries were usable for some Windows distribution. It would > > be different if Windows had a good package system with handles dependency > > conflicts and the like. If would be different if most of the win32 cross > > developer were using Debian. > > > How about win32 developers using kReactOS Debian distribution? Could > happen. Yes, and if that happened, they would be the critical mass needed to initiate that progress, and I'd be happy to support that movement. However, it's impossible for me to start that movement, because I'm not interested in "kReactOS Debian" in any way. At the moment, the only community I'm getting help from is the "community" of win32 cross developers which develop on various Linux and *BSD systems. Of course, "our" community and the "kReactOS Debian" community can and should help each other. My script is a first step. Supporting Debian sources may be the next one. But I will not make that effort for an imaginary community that currently consists of exactly 0 people. I already wasted too much time for such projects. I'd be happy to support that community, if your "Could happen." really happens some day. > > But all that isn't the case. So it's just a lot of extra-work without > > any benefits. > > > If you have time, file wishlist patches against some of the Debian > packages please. You may be able to simplify your script in the future > by making use of debian/rules files. Currently, that would make things more complicated. > You might even consider asking for > some of the build options to become easier to use via upstreams. That kind of patches is called "dpkg-cross compatibility" and I already brought some of those patches into the packages. However, my patches were only partly accepted - mainly the use of CROSS* variables. Other parts of those patches like handling DLL files were rejected, and with hindsight I think it was the right decision of the maintainers. Any Debian-win32 distribution should have compatible directory structures and file naming schemas before it can expect a wider acceptance from the various package maintainers. > My wishlist for your script includes: > - Pulling from debian source packages instead of upstreams (different > URLs, fewer versions available, some versions might be removed more > quickly). Having some of the Debian patches may be useful. Using > Debian packages also encourages the community to maintain things in > Debian where there are usually more long term releases. The Debian patches are very interesting, the debian/rules aren't. That's currently my dilemma. Adjusting the existing debian/rules is more work than writing own ones, even when they're using cdbs. And even easier than writing an own debian/rules is to just put the build commands into my script. ;-) However, the debian/rules files are a good insiration. For example, I've taken a look at the debian/rules of "mingw32" and "smpeg" while writing my script. > - Optional pulling with apt (makes source cd's and other apt advantages > available. E.g. apt-cache) This would add complexity without a suitable benefit, because the script has already its own "cache", i.e. the download/ directory. > - making use of debian/watch files to find new upstream source (see also > dehs). This may not make sense as it can be risky to upgrade. The debian/watch mechanism is only slightly better than the portable "curl | sed" variant my script currently uses. > - Trying to use debian/rules when possible (sounds like almost never) See above. IMHO that doesn't make any sense. > - Making it easier to use dll versions of the libraries (although I'm > not sure it makes sense for any libraries you're using) Just replace --disable-shared with --disable-static on any library you like to link dynamically. > - A native win32 version (no changes? might just require some mingw like > packages like bash, curl?... to run the script and its commands) Initially, the script was designed to run on MSYS as well. This fails for two reasons: 1) My script uses wget consequently, but could be easily rewritten to use curl instead. However, MSYS has neither wget nor curl. 2) Some libraries need additional build tools like perl and python, even when you "./configure --disable..." any perl/python stuff. Problem 1) can be solved by providing a full download/ directory, or by installing wget into your wget environment. Problem 2), however, requires more work. It could work if you install those extra tools as well. But in that case you might want to simply use Cygwin instead. I didn't test my script in MSYS, an I don't think it's worth the work. One important part of my concept is to use the already avaiable unix tools instead of having to build them, too. > - ReactOS build environment creation (certain gcc & binutil packages > won't work). This env would require limiting to certain versions of > code, and should probably not pull in extra libraries. I don't know what that means exactly, as I don't work with ReactOS. I'm not qualified for that job, but I offer you my help when you want to try this. > - Making more libraries available That's everyone's wish. ;-) > I suppose the phrase is "patches welcome" for me, but I thought I'd > share my wishes anyways in case some are quick/easy for you/others. > There's also a slight chance I'll look back at this message and do some > work on this. Sorry, but most of your wishes are I had to reject for practical reasons. Simplicity, portability and transparency are the big strengs of the script, I don't want to endanger them without real benefits. However, two things remain feasible: a) adding new libs (for ReactOS or others) b) using Debian sources and patches For a), just be more concrete. What libs do you need? Maybe I'll work on some of them. I got library-wishlists from other people as well. For b), we need more: We need to work on a good concept. I told you some of the problems, maybe you have some good ideas. Greets, Volker -- Volker Grabsch ---<<(())>>--- Administrator NotJustHosting GbR -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
