Re: INN indentation

Hi Russ,

>> It seems like that all inclusions of "clibrary.h", or of both "clibrary.h"
>> and "config.h", should be changed to only one inclusion of
>> "portable/system.h".
>> And "clibrary.h" moved to "portable/system.h".
> 
> I think that's right.

Change done.



> That reminds me that I want to take a moment now that everything is in Git
> and switch the INN build system over to Automake, since I think it would
> get rid of a bunch of maintenance gotchas and chores that currently have
> to be done manually.  It will raise a few questions, though, such as
> whether the additional human-readable information in MANIFEST is useful
> when it's no longer necessary to generate a distribution.

I am unsure people really look at the MANIFEST...
We can get rid of it if no longer useful to pick up the right files to 
include in a release.



>> I think the namespace is ok (I'm not aware of any complaints about it).
>> Unless I am missing something, there isn't any work to do for that task,
>> is it?
> 
> So, the problem with the namespace is that we create a shared library that
> has tons of random functions exported from it that don't share any common
> prefix, and hence sprawl all over the C function namespace.  (Stuff like
> concat, all the buffer_* stuff, etc.  Often they have their own namespace,
> like QIO, but sometimes they don't nad it's not really consistent.

Understood, thanks.



> For a well-behaved shared library, ideally all that stuff should have inn_
> or INN_ prefixes.  But that's a huge pain in the ass to do because it's
> little changes all over the source base, and I'm not sure if it's a good
> use of time.  This is part of why, for example, the Debian packages
> install the libinn shared library out of the normal library search path,
> since it's not entirely a well-behaved shared library.  (Also it doesn't
> have symbol versioning.)
> 
> Another approach rather than rename everything would be to shrink the
> symbols provided by the shared library down considerably to only things
> that make sense for external programs seeking to have API access to INN
> data files, namespace all of those, and then hide all the other symbols.
> This would probably involve creating a separate static library with the
> internal utility code like buffer and linking that with all the
> executables.  This is what I do for other projects with a shared library
> to keep the shared library ABI minimal.  Again, not sure it's worth it,
> and it would break any out-of-tree software that really uses libinn for
> its random utility functions.

Sounds like a great amount of work, with no real direct benefit...



>> Time has come to get rid of "inn/defines.h" at the same time,
>> and just include the necessary headers instead of it.
> 
> Yup, that would be great.

Also done.

-- 
Julien ÉLIE

« Il est difficile de discuter avec des gens qui ne peuvent pas entendre
   et qui ne veulent pas entendre. » (Julius Welhausen)
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers