Christian Parpart
2008-Oct-09 02:20 UTC
[PATCH] btrfs-progs: autotoolized and splitup into {libbtrfs,tools,tests}
Hi, this now makes use of autoconf/automake/libtool suite, thus, enabling a wider range of platforms etc. Although, I''ve split up the build into tools, lib, and tests, making it possible for 3rd-parties to link against libbtrfs now. Patch URL: http://ninchens.net/~trapni/btrfs/btrfs-progs-autotooled-splitup.diff Best regards, Christian Parpart. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Christoph Hellwig
2008-Oct-09 05:55 UTC
Re: [PATCH] btrfs-progs: autotoolized and splitup into {libbtrfs,tools,tests}
On Thu, Oct 09, 2008 at 04:20:49AM +0200, Christian Parpart wrote:> Hi, > > this now makes use of autoconf/automake/libtool suite, > thus, enabling a wider range of platforms etc. > Although, I''ve split up the build into tools, lib, and tests, > making it possible for 3rd-parties to link against libbtrfs now.I don''t think allowing 3rd parties to link against it is a good idea. It''s basically the kernel code with a few wrappers around it, and will change a lot over time. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Christian Parpart
2008-Oct-09 06:47 UTC
Re: [PATCH] btrfs-progs: autotoolized and splitup into {libbtrfs,tools,tests}
On Thursday 09 October 2008 07:55:58 Christoph Hellwig wrote:> On Thu, Oct 09, 2008 at 04:20:49AM +0200, Christian Parpart wrote: > > Hi, > > > > this now makes use of autoconf/automake/libtool suite, > > thus, enabling a wider range of platforms etc. > > Although, I''ve split up the build into tools, lib, and tests, > > making it possible for 3rd-parties to link against libbtrfs now. > > I don''t think allowing 3rd parties to link against it is a good idea. > It''s basically the kernel code with a few wrappers around it, and will > change a lot over time.I already noticed that, and this is another thing: Why is the kernel module and the userland duplicating so much code? As of ZFS, they''ve written a set of libraries (libzfs, libzpool, kernel compat libs, ...) that are shared between userland and kernel, thus, making porting to other platforms lots of easier. If btrfs would do the same aproach, it could also benifit from a fuse frontend (aside the kernel module) to be used for debugging purposes, think of gdb, valgrind (or cachegrind) to mention the most interesting ones. I talked to yangzheng about this, and he said that this just seems to lag a volunteer to do, however, *after* the disk format is completed. Regards, Christian Parpart. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
David Woodhouse
2008-Oct-09 10:45 UTC
Re: [PATCH] btrfs-progs: autotoolized and splitup into {libbtrfs,tools,tests}
On Thu, 2008-10-09 at 04:20 +0200, Christian Parpart wrote:> this now makes use of autoconf/automake/libtool suite,Please, God, no. I will personally buy a licence for GNU make for anyone who needs one. -- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Christian Parpart
2008-Oct-09 13:55 UTC
Re: [PATCH] btrfs-progs: autotoolized and splitup into {libbtrfs,tools,tests}
On Thursday 09 October 2008 12:45:06 David Woodhouse wrote:> On Thu, 2008-10-09 at 04:20 +0200, Christian Parpart wrote: > > this now makes use of autoconf/automake/libtool suite, > > Please, God, no. > > I will personally buy a licence for GNU make for anyone who needs one.In that case, you shall know what license automake is under, too, and despite your impressions i read above, if you don''t want it, fine with me, but stick to reasonable facts instead of religios talk next time you press a reply button. Regards, Christian Parpart. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Eric Anopolsky
2008-Oct-09 21:52 UTC
Re: [PATCH] btrfs-progs: autotoolized and splitup into {libbtrfs,tools,tests}
On Thu, 2008-10-09 at 15:55 +0200, Christian Parpart wrote:> On Thursday 09 October 2008 12:45:06 David Woodhouse wrote: > > On Thu, 2008-10-09 at 04:20 +0200, Christian Parpart wrote: > > > this now makes use of autoconf/automake/libtool suite, > > > > Please, God, no. > > > > I will personally buy a licence for GNU make for anyone who needs one. > > In that case, you shall know what license automake is under, too, > and despite your impressions i read above, if you don''t want it, fine with me, > but stick to reasonable facts instead of religios talk next time you press a > reply button.I nearly tried to make an argument against the autotools last night. Today, I decided that I would rather explain why I had such a visceral reaction to the announcement and not try to convince anyone of anything. The GNU autotools kept me out of FOSS development for the better part of a decade. They obviously solve a common and important problem, or they wouldn''t be so widespread. But the knowledge gap between what can be gleaned from a "learn C" book the knowledge required to navigate a project built with autotools is enormous. At first I thought I was alone, but when I shared my frustration with my programming friends I found all but one had the same problem. I tried reading the entire collection of autotools documentation, but that didn''t help very much. I tried installing anjuta, hoping that it would cover up the complexity of the build process and just let me hack, but it never seemed to work correctly. The problem, in my opinion, is that the autotools are chock full of solutions to problems that many programmers have not yet encountered. Viewed through that lens, they look like cruft. And if files associated with autoconf and automake look like cruft to someone, that''s a truly massive amount of cruft to wade through just to get started programming. There''s no way for me to tell whether bringing autotools to the btrfs userspace code will help or hinder the project. However, I feel fairly certain that it will exclude a large class of potential contributors from the development process. Maybe people are opposed to growing the btrfs development community by incorporating programmers who are not well versed in the problems that arise when porting software across different distributions and platforms. Maybe only bad programmers don''t like autoconf. Decide for yourselves. :) Cheers, Eric
David Woodhouse
2008-Oct-09 22:07 UTC
Re: [PATCH] btrfs-progs: autotoolized and splitup into {libbtrfs,tools,tests}
On Thu, 2008-10-09 at 15:52 -0600, Eric Anopolsky wrote:> On Thu, 2008-10-09 at 15:55 +0200, Christian Parpart wrote: > > On Thursday 09 October 2008 12:45:06 David Woodhouse wrote: > > > On Thu, 2008-10-09 at 04:20 +0200, Christian Parpart wrote: > > > > this now makes use of autoconf/automake/libtool suite, > > > > > > Please, God, no. > > > > > > I will personally buy a licence for GNU make for anyone who needs one. > > > > In that case, you shall know what license automake is under, too, > > and despite your impressions i read above, if you don''t want it, fine with me, > > but stick to reasonable facts instead of religios talk next time you press a > > reply button. > > I nearly tried to make an argument against the autotools last night. > Today, I decided that I would rather explain why I had such a visceral > reaction to the announcement and not try to convince anyone of anything. > > The GNU autotools kept me out of FOSS development for the better part of > a decade. > > They obviously solve a common and important problem, or they wouldn''t be > so widespread.Really, do they? In my experience, they cause more problems than they solve. It''s mostly just cargo-cult programming. If you have decent, portable code, and decent makefiles, you really don''t need the baroque pile of turd that autotools inflicts on you. If I ever see a btrfs-progs build trying to detect what kind of FORTRAN compiler I have on the system, I''m never going to touch btrfs-progs again. Life''s just too bloody short to deal with that kind of crap. -- dwmw2 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Christian Parpart
2008-Oct-10 01:01 UTC
Re: [PATCH] btrfs-progs: autotoolized and splitup into {libbtrfs,tools,tests}
On Friday 10 October 2008 00:07:23 David Woodhouse wrote:> On Thu, 2008-10-09 at 15:52 -0600, Eric Anopolsky wrote: > > On Thu, 2008-10-09 at 15:55 +0200, Christian Parpart wrote: > > > On Thursday 09 October 2008 12:45:06 David Woodhouse wrote: > > > > On Thu, 2008-10-09 at 04:20 +0200, Christian Parpart wrote: > > > > > this now makes use of autoconf/automake/libtool suite, > > > > > > > > Please, God, no. > > > > > > > > I will personally buy a licence for GNU make for anyone who needs > > > > one. > > > > > > In that case, you shall know what license automake is under, too, > > > and despite your impressions i read above, if you don''t want it, fine > > > with me, but stick to reasonable facts instead of religios talk next > > > time you press a reply button. > > > > I nearly tried to make an argument against the autotools last night. > > Today, I decided that I would rather explain why I had such a visceral > > reaction to the announcement and not try to convince anyone of anything. > > > > The GNU autotools kept me out of FOSS development for the better part of > > a decade. > > > > They obviously solve a common and important problem, or they wouldn''t be > > so widespread. > > Really, do they? In my experience, they cause more problems than they > solve. It''s mostly just cargo-cult programming. > > If you have decent, portable code, and decent makefiles, you really > don''t need the baroque pile of turd that autotools inflicts on you. > > If I ever see a btrfs-progs build trying to detect what kind of FORTRAN > compiler I have on the system, I''m never going to touch btrfs-progs > again. Life''s just too bloody short to deal with that kind of crap.whether btrfs to be using autotools or not, the other kind this patch addressed seems to be more important to me: project modularization. So please let me clarify why. The code being shared between kernel space and user space is much more then a single fragment of code, this can be verified using your favorite diff tools, although, the wiki states it is just to be meant this way, to share as much code as possible, which (from my point of view) seems to be quite logic, though, making a libbtrfs.a(or .so for user space) out of it is the very certain way to go from here. And while the kernel land code seems more up-to-date than the one found in user-land, it''s been at least a start, from project structure point of view, and for the sake of a clean project design. Despite that, there actually are other tools that might benifit from libbtrfs, think of low-level backup tools (e.g. partimage), analytical tools, a fuse- btrfs frontend (makes debugging/developing easier), and maybe more. Best regards, Christian Parpart. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
David Woodhouse
2008-Oct-10 06:38 UTC
Re: [PATCH] btrfs-progs: autotoolized and splitup into {libbtrfs,tools,tests}
On Fri, 2008-10-10 at 03:01 +0200, Christian Parpart wrote:> whether btrfs to be using autotools or not, the other kind this patch > addressed seems to be more important to me: project modularization.That makes a certain amount of sense, but should definitely be submitted as a separate patch. And it would probably be best to generate it with ''git-diff -M'' so that renamed files are shown as such. rather than deletion and addition. That''ll make your patch far more reviewable. I''m still not convinced that third party code should be linking against a libbtrfs just yet, but that doesn''t mean it shouldn''t be set up to allow that to happen in future. -- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html