Use a central config.h instead of multiple *.h.in files

[GoogleCodeExporter]

Use a central config.h instead of multiple *.h.in files

[GoogleCodeExporter]

You are right, it is a pain to change existing files.  I had organized the code 
this
way to keep the number of installed header files to a minimum.  It's not clear 
that
this is the right trade-off between ease of development and ease of maintainence
after deployment.  I'll play around with reorganizing along the lines you 
suggest,
and if it looks like it will work out well, include that in the next release.

Original comment by [email protected] on 20 Oct 2008 at 11:26

• Changed state: Started

[GoogleCodeExporter]

Thanks a lot for your (lightning fast) responses to my tickets, looking forward 
to
the next version and I'll definitely try to submit any useful changes/fixes I 
might
have to this project. The trouble is that so far the library looks almost 
perfect so
I haven't got any ;-)

Thanks again!

Original comment by [email protected] on 20 Oct 2008 at 11:32

[GoogleCodeExporter]

Thanks for your kind words!  It makes me a bit guilty about what I'm about to 
say. :-}

After playing around with changing the header files, I remembered the reasons 
to use
.in files.  The major one is that without them, we'll need a config file, as 
part of
the distribution, that defines a lot of macros (11 so far).  This means that any
program users write that #include template.h will be polluted by these macros.  
(And
unfortunately, they *do* need to be macros, since they're used for computed 
includes
and other situations where we can't use variables or other in-language 
constructs.) 
If another program happens to use the same macro name, there will be 
collisions, and
annoyance will ensue.

While we can pick suitably obscure macro names to minimize this possibility, 
it's
still not very clean.  I'd rather avoid the problem altogether by using .in 
files. 
It does make it annoying to edit these files -- rather annoying, for windows -- 
but
I'd rather annoy developers than end-users. :-)

If it makes it easier, I'm happy to take patches that just modify the windows .h
files.  I'll do the back-porting to unix myself.  That means you should just 
have to
edit one file, and it should be pretty straightforward.

Original comment by [email protected] on 21 Oct 2008 at 6:32

• Changed state: WontFix

[GoogleCodeExporter]

It's true that typical use of config.h pollutes the user namespace with HAVE_XXX
macros and such. And I definitely applaud your efforts to avoid this, it can be 
a
real problem when using multiple libraries disagreeing over what exactly 
HAVE_BAZ mean.

However I think it's not difficult to avoid this issue by doing 2 things:

- Use a unique prefix: the risk of conflict is great for HAVE_HASH_MAP but 
almost
non-existent for GOOGLE_CTEMPLATE_HAVE_HASH_MAP. Definitely much lesser than 
e.g.
_TEMPLATE_H used as the header guard (independently of this issue I'd definitely
recommend using the project name as a prefix for the guard symbols...).

- If you think that the risk is still too great, then, in addition to including
config.h at the top of each file, also include unconfig.h (well, maybe with a 
better
name) which would #undef all these symbols at the end of every file. This would
ensure that if you include this library files first there is no conflict which 
really
should be good enough.

But IMO even just using the unique (prefixed by project name) symbols should be 
ok,
you do already use things like CTEMPLATE_DLL_DECL and why would the risk of 
conflict
be greater for CTEMPLATE_NS_BEGIN than for this one?

Original comment by [email protected] on 22 Oct 2008 at 4:00

[GoogleCodeExporter]

You are right, there are various ways one could make this work with a config.h,
and/or reduce the chances of collision.  But I'd rather remove the chance 
entirely by
using .in files.  I think it's possible to reduce the annoyance in windows
development, even in a .in system, to make it not too onerous to use.

As for _TEMPLATE_H, you're absolutely right.  (It's also an illegal symbol to 
use,
since it's reserved for use by the compiler.)  We've been fixing these as we've 
been
editing these files anyway -- to use project names as you suggest -- but it 
seems
like there are still some left to change.

Original comment by [email protected] on 23 Oct 2008 at 4:59