* Borislav Petkov <[email protected]> wrote:
> On Fri, Nov 22, 2013 at 04:54:25PM +0100, Ingo Molnar wrote:
> > comet:~/tip/tools/perf> ls util/*.h
> > util/annotate.h util/data.h util/fs.h
> > util/parse-events-bison.h util/probe-event.h util/sort.h
> > util/thread.h util/values.h
> > util/build-id.h util/debug.h util/header.h
> > util/parse-events-flex.h util/probe-finder.h util/stat.h
> > util/thread_map.h util/vdso.h
> > util/cache.h util/dso.h util/help.h util/parse-events.h
> > util/pstack.h util/strbuf.h util/tool.h
> > util/xyarray.h
> > util/callchain.h util/dwarf-aux.h util/hist.h
> > util/parse-options.h util/quote.h util/strfilter.h util/top.h
> > util/cgroup.h util/event.h util/intlist.h util/perf_regs.h
> > util/rblist.h util/strlist.h util/trace-event.h
> > util/color.h util/evlist.h util/levenshtein.h util/pmu-bison.h
> > util/run-command.h util/svghelper.h util/types.h
> > util/comm.h util/evsel.h util/machine.h util/pmu-flex.h
> > util/session.h util/symbol.h util/unwind.h
> > util/cpumap.h util/exec_cmd.h util/map.h util/pmu.h
> > util/sigchain.h util/target.h util/util.h
> >
> > That is pretty healty granularity IMO.
> >
> > Do we want a separate directory for each one?
>
> For each single one of them? This would be insane.
Not necessarily, if the number goes up - obviously then we'd also want
to add some second directory structure to organize them into broad
categories or so.
> > I don't see a big problem with doing that, but it could be kept in
> > tools/lib/util/ or tools/lib/core/ as well,
>
> That's much better :)
>
> > _as long as they are not lumped together
>
> Why not a single .a?
Unnecessarily longer build time.
> > That also means that these bits shouldn't really be librarized in
> > the classical sense into a single .a and linked into whatever tool
> > uses it, but should be used individually as singular targets with
> > clean .h interfaces to utilize them topically.
>
> Yeah, but why?
If a tool uses just a handful of these (hopefully quickly increasing
number of) facilities then it should not be burdened by building it
all.
> > That also means that utilities won't run into any dependency
> > problems, and the build will be faster as well as it all will be a
> > single dependency graph within a single make session.
>
> That's maybe the only half-reason for not lumping them together I've
> read so far. I say half-reason because the preprocessor already will
> include only stuff it needs. And if that were a problem, glibc
> would've been multiple libs too.
The preprocessor does nothing with the .a - eliminating extra stuff
from the .a is a link time step, and that means the whole .a will be
built first ... just to throw away bits of it.
( Also, arguably, from a sw design POV glibc should probably have been
multiple libs, but that's water down the bridge. No need to
repeat/clone such mistakes though. )
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
