Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Splitting config.h.in in two files. #303

Closed
carlo-bramini opened this issue Jun 3, 2023 · 1 comment
Closed

Splitting config.h.in in two files. #303

carlo-bramini opened this issue Jun 3, 2023 · 1 comment
Assignees
Labels
wontfix This will not be worked on

Comments

@carlo-bramini
Copy link
Contributor

I would like to suggest to split config.h.in in two files.
The first file is used by autotools as template for the macros emitted at configure time, that can be something like that:

/*
 * Configuration file for Mini-XML, a small XML file parsing library.
 *
 * https://www.msweet.org/mxml
 *
 * Copyright © 2003-2020 by Michael R Sweet.
 *
 * Licensed under Apache License v2.0.  See the file "LICENSE" for more
 * information.
 */

/*
 * Version number...
 */
#define MXML_VERSION	""


/*
 * Inline function support...
 */
#define inline


/*
 * Long long support...
 */
#undef HAVE_LONG_LONG_INT


/*
 * Do we have the *printf() functions?
 */
#undef HAVE_SNPRINTF
#undef HAVE_VASPRINTF
#undef HAVE_VSNPRINTF


/*
 * Do we have the strXXX() functions?
 */
#undef HAVE_STRDUP
#undef HAVE_STRLCAT
#undef HAVE_STRLCPY


/*
 * Do we have threading support?
 */
#undef HAVE_PTHREAD_H

and then there is another file, that we may call common.h for example, which includes the generated config.h file and it does all operations moved outside like doing #include, #ifdef and so on. This is a fix that I made when adding support for CMake in my package for CYGWIN, because the common file would be the same for both autotools and CMake. I could write my config.h.cmake by keeping the same content of current config.h.in, but splitting the template allows to have less duplicated code, which would simplify the maintenance if CMake support will be added in the future.

What do you think?

@michaelrsweet
Copy link
Owner

While I've had a few requests to support cmake, and there is another issue and a PR for this, I do not want to make any changes towards this at this time.

@michaelrsweet michaelrsweet self-assigned this Jun 3, 2023
@michaelrsweet michaelrsweet added the wontfix This will not be worked on label Jun 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

2 participants