On Aug 2, 2007, at 1:38 PM, James Carlson wrote: > eric kustarz writes: >> Bart mentioned that he would like more than just a single executable >> in the libmicro directory. Something like: >> /usr/benchmarks/libmicro/libmicro (executable) >> /usr/benchmarks/libmicro/README >> /usr/benchmarks/libmicro/libmicro.tar.gz > > If there's a reasonable man page, what would be in the README? > > I'm really hesitant to ask what's in that tar.gz file. That doesn't > look like a way to deliver packaged software. :-/ > > If there's a good case to be made that directories would be needed > here, then I'm ok with it, but I don't quite see anything that > establishes that case. That's particularly true given that the > "extra" stuff is tucked neatly away in /usr/lib/ where it won't hurt > anyone. > > Perhaps a more complete explanation of /usr/benchmarks would help.
Sure thing. If we allow benchmarks to have their own directory (such as /usr/benchmarks/libmicro/), then we can allow that benchmark to do what it wants in that directory. This would make porting much easier, less mangling of the source. It turns out that in filebench there is just a simple #define that specifies where everything under /usr/lib/filebench lives. So moving from platform to platform will be easy (if /usr/lib/filebench is not an option). Other benchmarks may have harder issues when having to place the main executable (if there only is one) in /usr/benchmarks, and the rest of their private files in /usr/lib/<your_fav_benchmark_here>. Bart can comment on his plans for having a real directory for libMicro to utilize. Having /usr/benchmarks essentially be /usr/benchmarks/bin seemed overly restrictive. eric
