smaller / decoupled `filesystem' module?
I recently had a need to fix some code which got a list of files in a directory, and needed to work across Linux / OS X 10.4+ / Windows. I was thinking of unifying it to use boost filesystem instead of some `#if not posix, do this, #else use opendir/readdir/etc. code.' So I turned to boost.filesystem. We're including boost piecemeal in our repo, and so I went to add it and adapt `filesystem' to our build system. Upon build, it seemed to require some additional boost headers, so I added them; goto 10. After a bit of this, I realized the new boost code was quite a bit larger than my entire ~5 meg repository up to that point: I'd needed to pull in MPL, for example, which is over > 6 meg. This is a minor part of the application we're writing, so I can't really justify the size. Has anybody out there written a `decoupled' filesystem, with less dependencies on other boost libraries? Even a trimmed down version would probably suit or needs for quite some time. Thanks, -tom
tom fogal пишет:
This is a minor part of the application we're writing, so I can't really justify the size. Has anybody out there written a `decoupled' filesystem, with less dependencies on other boost libraries? Even a trimmed down version would probably suit or needs for quite some time.
As I understand you, your problem not a size of boost.filesystem or how many dependencies it has. The problem is that boost.filesystem can't be integrated into your build system with one simple action. Am I right?
Konstantin Litvinenko <to.darkangel@gmail.com> writes:
tom fogal пишет:
This is a minor part of the application we're writing, so I can't really justify the size. Has anybody out there written a `decoupled' filesystem, with less dependencies on other boost libraries? Even a trimmed down version would probably suit or needs for quite some time.
As I understand you, your problem not a size of boost.filesystem or how many dependencies it has. The problem is that boost.filesystem can't be integrated into your build system with one simple action. Am I right?
No, adding external code to our tree is quite easy and I don't mind spending the 20 minutes it takes to do so. The size is really the root issue. I asked for a decoupled version because boost.filesystem is actually pretty small: tf@shigeru boost_1_38_0 du -hcs libs/filesystem/src/ boost/filesystem boost/filesystem.hpp 72K libs/filesystem/src/ 148K boost/filesystem 4.0K boost/filesystem.hpp 224K total tf@shigeru boost_1_38_0 so if I didn't need to pull in e.g. MPL to get filesystem, it wouldn't be as big a deal. -tom
On Tue, Apr 7, 2009 at 8:27 PM, tom fogal <tfogal@alumni.unh.edu> wrote:
Upon build, it seemed to require some additional boost headers, so I added them; goto 10.
There's an utility called bcp to extract particluar pieces of boost ( http://www.boost.org/doc/libs/1_38_0/tools/bcp/bcp.html). boost-root-dir$ bcp filesystem /destination_directory will copy all the dependencies you need. This is a minor part of the application we're writing, so I can't
really justify the size.
I won't give you any answer, it's just my blah-blah: I had a similar problem when I wanted to use boost program options -- the guys I was working with told me that it's just rediculous to pull such a load of code that exceeds or own code base by an order of magnitude. My point here that couple of dozens megs of boost code in your repository does not harm anyone. Okay, it's big, but who cares? So what? We now have plenty of space -- the space is not a problem per se -- our perception is the problem. What is the real show stoppage here, except someone's dim unconscious feelings? Anyway I was never persuasive enough -- they forced me to reinvent the wheel and do stuff by our own hands. So in your case, like Konstantin Litvinenko (I suspect) tried to point out, there is no reason to stop yourself from using boost::filesystem. Regards, Anton Daneyko
On Wed, Apr 8, 2009 at 1:51 AM, Anton Daneyko <self@mezhaka.com> wrote:
On Tue, Apr 7, 2009 at 8:27 PM, tom fogal <tfogal@alumni.unh.edu> wrote:
Upon build, it seemed to require some additional boost headers, so I added them; goto 10.
There's an utility called bcp to extract particluar pieces of boost (http://www.boost.org/doc/libs/1_38_0/tools/bcp/bcp.html). boost-root-dir$ bcp filesystem /destination_directory will copy all the dependencies you need.
This is a minor part of the application we're writing, so I can't really justify the size.
I won't give you any answer, it's just my blah-blah: I had a similar problem when I wanted to use boost program options -- the guys I was working with told me that it's just rediculous to pull such a load of code that exceeds or own code base by an order of magnitude. My point here that couple of dozens megs of boost code in your repository does not harm anyone. Okay, it's big, but who cares? So what? We now have plenty of space -- the space is not a problem per se -- our perception is the problem. What is the real show stoppage here, except someone's dim unconscious feelings? Anyway I was never persuasive enough -- they forced me to reinvent the wheel and do stuff by our own hands.
So in your case, like Konstantin Litvinenko (I suspect) tried to point out, there is no reason to stop yourself from using boost::filesystem.
Why not pull in the entire Boost then? It certainly wouldn't hurt, would it? :) I think that the request to keep coupling in boost::filesystem in check is valid. The fact that bcp exists means that many people are interested in acquiring just a part of Boost, which also implies that they don't want to depend on a lot of code. Your might be correct in your analysis, but without knowing enough details about each use case, you are only speculating. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski <emildotchevski@gmail.com> writes:
On Wed, Apr 8, 2009 at 1:51 AM, Anton Daneyko <self@mezhaka.com> wrote:
On Tue, Apr 7, 2009 at 8:27 PM, tom fogal <tfogal@alumni.unh.edu> wrote:
There's an utility called bcp [. . .]
Thanks, I'd heard it mentioned on this list, but it didn't click in this case. I'll give it a shot.
This is a minor part of the application we're writing, so I can't really justify the size. [snip] My point here that couple of dozens megs of boost code in your repository does not harm anyone. Okay, it's big, but who cares? So what? [snip] Why not pull in the entire Boost then? It certainly wouldn't hurt, would it? :)
<g> You have a good point that the space is not really the issue. The size is an (admittedly poor) indicator of other issues which *are* important though, such as build times. More code means more maintainence burden too: if there is a new version of b.fs which fixes a bug we care about, do we upgrade b.mpl as well? What if we later have another library which also depends on b.mpl? It gets complicated quickly. -tom
participants (4)
-
Anton Daneyko -
Emil Dotchevski -
Konstantin Litvinenko -
tom fogal