From: Robert N. <ro...@th...> - 2006-06-30 13:50:59
|
I'll take care of these suggestions with the exception of configure support. I'd prefer not to use configure for the win32 stuff for the following reasons. Configure is used for three purposes in Bacula: Platform Configuration, Dependency Location, and Runtime Configuration. On Windows the platform is well-defined. Locating the dependencies elsewhere doesn't make as much sense in a cross-compile environment. I'm moving runtime configuration (password generation, conf file generation, etc) into the installer. Configure tends to get in the way when doing cross-compiles. (I've experienced this trying to build the dependencies). It makes it much harder to build both the native and windows versions in the same source tree. > -----Original Message----- > From: Kern Sibbald [mailto:ke...@si...] > Sent: Friday, June 30, 2006 6:26 AM > To: Robert Nelson > Cc: bacula-devel > Subject: Re: depkgs script > > Hello Robert, > > I've copied the developer's list on this, so they can see > what is going on and > particularly because of the last item (link below). > > On Friday 30 June 2006 14:37, Robert Nelson wrote: > > I would like to check in the new script and associated > patch files. Where > > in the tree should I put them? I was thinking maybe in a > subdirectory > > under win32, but I'm worried that folks might try and run them there > > screwing up the directory structure. Another alternative > is to check in > > the tar file into src/win32 but then we lose version control of the > > contents. > > > > I guess a third alternative would be to have the > depkgs-mingw32 directory > > be under src/win32 and have the script live in src/win32 with > > build-win32-cross-tools. However I believe you had > concerns that the > > third party packages being built in the source tree would > cause confusion. > > Yes, I guess it would be good to have in the source tree to > have the script > under CVS rather than just releasing it as depkgs-mingw32. > > I would suggest that we add it to the src/win32 directory, > and modify it in > the same way as the build-win32-cross-tools script so that > installs the > depkgs-mingw32 at the correct level (i.e. one above the > bacula source tree). > I committed mingw-utils.patch to the src/win32 directory, but > perhaps we > should create a mingw32 patches directory and move all the > patches in there. > > Here are two other thoughts that are not at all urgent: > 1. It might be nice to put build-win32-cross-tools and the > depkgs-mingw32 > build script under ./configure. That way, we can make more > of the paths > absolute, and possibly allow the user to move them to other locations > (additions later to ./configure options). > > 2. It might be a good idea to have the build-win32-cross-tools to > automatically run the depkgs-mingw32 script. > > Scott Barninger sent me the following link: > http://software.newsforge.com/software/06/06/23/1728205.shtml?tid=150 > > Now to date, I think we are in full compliance with the GPL > -- that is we > distribute all the source code that we use with the exception of the > Microsoft proprietary code. I don't think anything we are > currently doing > will create any problems, but we need to take a careful look > at this. If we > are patching GPL'ed code and then distributing it in binary > form, I think we > may be obligated to release the source code of that patched > code as well. > This may imply that we will need to release a depkgs-mingw32 > directory > containing all the "pre-loaded" source code. This is no big > deal, but I > would like to hear comments on this ... > > > -- > Best regards, > > Kern > > ("> > /\ > V_V > |