Alex Rousskov wrote:
On Wed, 2008-04-23 at 16:31 +1200, Amos Jeffries wrote:
First step is to generate a new folder, for this proposal I'll call it
'squidbits'.
How about squidsquidsquidbits, to make sure we all realize this is a
squid header file?
Seriously, I would prefer just "bits". If we must put squid inside
squid, then please use squid_bits to make the name readable.
It would eventually reside in Alex's ./compat directory as
./compat/squidbits. and is modelled on the kernel bits folder insofar as
nothing around squid is supposed to reference it directly and it contains
all the 'expert only' compat and type setup code needed.
That sub-directory would contain a file for each OS requiring OS-specific
tuning.
* squidbits/mswin.h
* squidbits/bsd.h (shared *BSD tuning)
* squidbits/linux.h (shared 'nix tuning)
* squidbits/freebsd.h (FreeBSD-only tuning)
And some bits-files for specific tuning.
* squidbits/fdsetsize.h (for the global FD_SETSIZE logics currently in
config.h)
* squidbits/resinit.h (for the global res_init logics currently in config.h)
* others maybe for logics currently in squid.h
I am not sure we really need the compat/bits, but I am not against it.
To perform some of those OS/config-specific details that need to be
global to the entire squid, defined first. But only under very specific
auto-conf detected environments.
The global BSD kernel API emulation done for Windows and Linux for two
examples.
There are also a number of things like system header overriding being
done in squid.h and config.h and their includes. Some can be migrated
out, but some can't (yet).
So why not put that in compat/?
Well, I'm imagining the compat/ parent directory itself having stuff
like the MD5.h specific small-scale compat which components might need
to share, but not the whole of squid. The semi-critical bits as I think
of them.
compat/includes and compat/lib you mentioned in your plans as being
propose for autoconf to perform complete squid-wide replacement of
missing header files or functions.
I thought of bits as the equivalent for manual developer use instead of
cluttering those up again.
What will happen is that you will have to place two-line wrappers in
compat/ so that the rest of the code can get access to some of the stuff
in compat/bits/. That's not a big deal.
May not be a big deal but I don't understand you.
Please explain by what you mean by having to us two-line wrappers. And
what form they would need to take (#if ... #endif ?? or makefile: if ...
fi ??).
Secondly migrating the existing config.h to do a guaranteed short sequence
of actions:
* include autoconf.h (autotools generated settings)
* include version.h (release maintainer generated settings)
* define OS-specific macros (ie #define _SQUID_FREEBSD_)
* include squidbits/types.h (currently squid_types.h)
* include squidbits/* for each OS.
It already has the first 4 sections, but the last section about squidbits
will be added in place of the existing direct-code which has so muddled
squid.h and is already starting to grow in config.h
This means config.h guaranteed:
* is the ONLY place to include anything from squidbits/*
* can be placed cleanly at the top of every .cc
* stays clean of any lengthy compat code in itself
Finally, is to seamlessly rename (squid.h -> old_dirty_squid.h) and
(config.h -> squid.h)
then continue the cleanups removing stuff from old_dirty_squid.h
Sounds good to me.
Thank you,
Alex.
--
Please use Squid 2.6.STABLE19 or 3.0.STABLE4
