[ccan] [RFC] ccan: rename config file to ccan_config.h

[Rusty Russell]

"Emilio G. Cota" <cota at braap.org> writes:
> On Sun, Mar 16, 2014 at 21:31:16 +1030, Rusty Russell wrote:
>> "Emilio G. Cota" <cota at braap.org> writes:
>> > From: "Emilio G. Cota" <cota at braap.org>
>> >
>> > This avoids clashes with library users' code, who might
>> > have already a config.h header file.
>> 
>> But why would they want a separate one for CCAN?  That's just fraught
>> with danger.
>> 
>> For example, there's nothing wrong with your config.h including
>> ccan/ccan_config.h.
>
> I'm not sure we're understanding each other. Let me explain in
> more detail.
>
> The itch that started this RFC is my current setup, which is
> admittedly  of questionable resilience. Out of laziness I just have
> ccan as a git submodule of a parent git repo. The Makefile in this
> parent project just depends on ccan/libccan.a, and if it cannot
> find it, it does `make -C ccan'. gcc in the parent project is then
> invoked with "-Iccan", so that "#include <ccan/foo/foo.h>" works.
>
> So, since I'm relying on the makefiles on ccan (and on its generated
> config.h), my parent project has trouble if it tries to create a config.h
> file. Note: this new config.h file is not meant to have anything to do
> with CCAN. I'm not sure I made this clear in my original post.
>
> I imagined I wouldn't be the only one relying on ccan's makefiles,
> which in practice ends up exposing the auto-generated config.h as a
> "library header file", hence the RFC to rename the header to something
> more unique.


Yes, the makefiles are more trouble than they're worth :(  They're
also not accurate, so changing a file doesn't mean libccan.a always gets
rebuilt.  They're basically there for my testing before upload.

My intent eventually is to get rid of them, in favour of a 'ccantool'
which can generate specific build files for your project.

The other problem with 'libccan.a' is that there's no reason that ccan
modules can't have clashing names.  And eventually they surely will,
making this approach untenable.  That will probably be the driver
to actually fix this :)

Meanwhile, may I suggest something like:

        ccan/libccan.a: ccan_config.h

        ccan_config.h: ccan/tools/configurator/configurator
        	ccan/tools/configurator/configurator $(CC) $(CCAN_CFLAGS) > $@.tmp && mv $@.tmp $@

Then make sure you #include <ccan_config.h> in your own config.h.

Cheers,
Rusty.