No standard configure constants in public headers

[mezzarobba]

This is an attempt to fix #1390 without hiding the FLINT_ constants
from users.

This is only taking care of the autotools part; I have no idea if the
cmake stuff needs changes. And I am certainly no autotools expert, so
there are probably things that could/should be improved. In particular,
I don't known if

CPPFLAGS:=@CPPFLAGS@ -DBUILDING_FLINT

is the right thing to do to include config.h only when buiding flint.

[AndreasEnge]

I have just tried it, and it solves the problem.

A drawback is the use of an additional preprocessor constant to diistinguish building flint from building a project using flint, but this has the advantage of minimising the modifications. Alternatively, one could include config.h into each flint source file, which would mean a lot of places to change; or include it only in places where it is needed, which would require a lot of work and present the danger of forgetting places.

Andreas

[mezzarobba]

A drawback is the use of an additional preprocessor constant to diistinguish building flint from building a project using flint, but this has the advantage of minimising the modifications.

I agree -- but I thought we could always simplify the architecture later on if this proves a problem. I'm not familiar enough with the flint source code to put the internal includes in exactly the right places. (If Fredrik likes it better to create a new header for internal stuff and include it in every C file, I can do that, of course.)

[mezzarobba]

@albinahlback, @fredrik-johansson, what do you think?

[albinahlback]

I will take a look at this after lunch time!

[fingolfin]

Thank you!

This looks good to me in principle, although I did not try it out locally (but @AndreasEnge did and it worked for him, that's good enough for me :-).

One caveat is that one has to be a bit careful when modifying the build system to ensure things keep working (i.e. when things are added/removed to config.h they may also need to be added/removed to flint-config.h...). Ideally we therefore would have at least one test which does make install and then tests the result. I think the Nemo.jl CI test in this repo does that?

There are more things I could say, but I think this is a very sensible quick solutions, and I agree that any improvements can be done later, if and when someone has the time and energy.

[mezzarobba]

One caveat is that one has to be a bit careful when modifying the build system to ensure things keep working (i.e. when things are added/removed to config.h they may also need to be added/removed to flint-config.h...).

Both config.h and flint-config.h are generated files; the only part that needs to be maintained is flint-config.h.in, and it is just a list of the definitions managed by autoconf that are considered public.