directory layout

Andrew Tridgell tridge at
Thu Jul 30 06:19:49 GMT 1998

The huge number of changes caused by the autoconf merge means that one
of the reasons for sticking with the current directory layout are
gone, namely keeping the 1.9.18->current diffs small. The diffs are
going to be huge no matter what.

So, right now we have an opportunity to do some rearrangement of the
source tree if we want to. I'd like some feedback on possible
changes. Please do _not_ implement any of these changes (even in a
separate branch). If we do decide to make changes then I will do it
via repository hacking to maintain the history. If any well meaning
person decides to do it themselves then we will be screwed. 

Personally I'd like to see a change, but not to a deep directory
structure like Luke wants. I find it a great pain wading through more
than 2 levels of directories. Samba is not a full OS - we don't need
seven levels of abstraction. There is also a problem with tags. etags
(and I presume ctags) allows you to easily find a function or macro
definition, but it doesn't allow you to find all _calls_ to a
specified function. I often want to know "where is this called from"
and for that I use grep. Using grep with several levels of directory
is a pain (yes, I know how to do it using find, but it's still a pain,
especially inside emacs grep mode)

Instead I'd like a shallow structure. Something like:

client/ - client only code

libclient/ - client side code used by smbd, smbclient, nmbd etc

system/ - code to handle very system specific stuff. basically
          functions that in an ideal world we would like to see
          in libc, but aren't.

smbd/ - code specific to smbd

nmbd/ - code specific to nmbd

lib/ - code used by more than one component

etc ...

We might even use the "include" option in make to have files
in subdirectories while still keeping a single level Makefile. I'd
have to see if enough platforms support it (ie. if any of the 9 I have
access to don't then we probably won't do it).


Note that it won't take much persuading to get me to vote for keeping
the current structure, but it will take a lot of extraordinarily well
argued prose to get me to accept a deep structure :-)

       Cheers, Tridge

More information about the samba-technical mailing list