2009/11/6 Graeme Gill <graeme@xxxxxxxxxxxxx>: > Automake isn't cross platform :- it isn't available on MSWindows > without installing a whole UNIX like environment, and I prefer > using Jam in any case since it's simpler to use. Perhaps some > other projects should switch to Jam too :-) Sure, but automake is the #1 build system that works on Linux, *BSD, and Solaris, which I'm guessing is the vast majority of your userbase right now. >>> * A heavily hacked up local version of libusb is present > > That's what it takes to make the project work reliably with all > the different instruments out there. While it would be great to > fix libusb so that the current version was suitable for > use with Argyll, I thought a release this November would > be better than next February... Well, I think fixing the problems in upstream libusb would probably help other projects out who are hitting the same bugs. Patching this locally does not contribute to the wider ecosystem, and makes it hard for you when libusb gets fixes and you have to manually apply them at each branch point. >>> * No public CVS, SVN or git tree is available > > My code base contains some proprietary code that makes it > difficult to make public. I'm not sure if there is some > arrangement that could accommodate what you're after, if > the use cases could be explained. Right, use cases: * I want to get access to the latest argyllcms code, that-is the beta tarball you announced with the fixes you've ack'd and applied since then * I want to see why a piece of code was changed in a commit you made a few months ago * I want to maintain a local branch on argyllcms with some more udev patches, and then propose them as a patchset Many other projects I work for have proprietary private branches. For reference, I used to work for a UK defence contractor which contributed code back into the open source community, and yet maintained private versions which had IP or private licence agreements. If a super-locked-down defence contractor can achieve this, then I'm sure it's pretty easy for you too. >>> * The licence has just changed, and the project has multiple licences > > That's the nature of assembling a project from a number of components. Right, that's not a problem for me per-se, I was just bringing it to your attention and trying to avoid yet further licence proliferation. > I'm not sure quite why that is. If you took the approach of > first building Jam and then using it to build Argyll, it might > be simpler (aren't you building Jam for the Free Type project anyway ?). No, jam isn't required to build any other component on my system. Jam has some pretty big bugs with multiarch and building on odd architectures. Quoting from the jam-users mailing list "[jambase is] notorious for bugs and the infrequency with which fixes are integrated" -- this isn't the stable project that a build system needs to be. But sure, it's your call as you are the maintainer. What I'm asking is for you to include the configure.ac and Makefile.am file _alongside_ the existing jam buildsystem. We'll maintain it, if it breaks, we'll fix it. You don't even have to include it in the release notes as a supported feature. > There has been some degree of hurt caused by differences between > distribution versions and upstream already, notably with breakages. Sure. The less input you get from distributions, the less likely they are to package your code and ship it in their repos. People will instead code for libraries they can find in RHEL, SLES and that sort of thing, which for now just includes littlecms and not a lot else. By making this hard to build, you're not making it easy for distributions to ship your code. By making it hard to contribute, you're making it hard for distributions to feed back patches to you. > accommodate changes to help people use the code, there are limits. > My aims are not necessarily the same as everyone who would like > to make use of Argyll (it's not a community project, and specifically > it's not a Linux community project - it runs on a wider set of platforms > than that. Making the code available under the AGPL is a compromise - > I'm trying to make it available as open source while retaining most > useful commercial opportunities for myself, hence my choice of the most > restrictive available open source license). Sure, and I can understand that. What I'm trying to make clear is that without opening up ArgyllCMS development it will remain a niche set of tools for the 0.01% of people that understand what a CM actually is. Without integrating with front end applications and with other system and session frameworks, ArgyllCMS is just a cool set of commandline programs that nobody knows really quite how to use. > I specifically chose Jam to avoid Automake, make etc., so no, > I'm not going to maintain an Automake build setup! Nobody is asking you to. Just include the files in the tarball (or zip file) so we can build it without all of the linux distributions having to essentially hack in a new build system. > It would be good to get over the libusb thing - it's just a user level > library, not a kernel driver or anything terribly important. Bttz. See my reply above. Using that logic you could copy over large chunks of libc and make changes there, which we both should agree is a bad idea. It is certainly harder pushing proper fixes upstream to libusb, but it's something you just have to do as a responsible maintainer. > The normal > pressures of development (ie. do I want to maintain a fork of such > a library) will probably sort out the duplication in due course (either > I'll get around to helping fix libusb so I can use it unaltered, or I'll > re-implement USB support within Argyll without using libusb.) I think it would be a shame to re-invent a userspace USB stack in this case, and it worries me that you think that's an option. Building a thriving and stable project is meant to be re-using components as much as possible, and benefiting from working together on a shared goal. Now, I'm aware I've done a fair bit of ranting, and I don't want to come over as as jackass as I do appreciate the work you're doing. I'm just getting passionate as ArgyllCMS is a project I believe can be a much larger part of the solution, otherwise ArgyllCMS is going to be replaced with frameworks that are much easier to build, contribute and use. Richard.