Re: [OpenSmalltalk/opensmalltalk-vm] Inlcude the Squeak headers after the C headers. This hsould also help fix (47b8d52)

I don't see sq.h and neither a guarded config.h. This means that _GNU_SOURCE might not be picked up, which might have effect on the C headers…

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Hi Tobias,

defines that alter system headers should be specified on the compiler command line, and hence belong in makefiles or project build specifications, etc.

Assuming one can safely alter the innards of a system include with defines in one's own header files is presuming a specific implementation and likely to break at a later time. The only rational thing to do is include system headers first. In this case I had made a mistake. I should have fixed it a long time ago.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Then every file that includes a system header should start with

#ifdef HAVE_CONFIG_H
#include "config.h"
#endif

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Really, I do think there should be as little defines on the cmdline and the Makefiles as possible

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

And what, pray tell me, defines HAVE_CONFIG_H?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

./configure

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

How does the define get to be defined at compile time?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

./confiugre set the CFLAGS accordingly.
Yes, via cmdline means.
That's why I said “ as little defines […] as possible“
imho '-DHAVE_CONFIG_H" should be the only define besides Debug flags.

some makefile generators also are pretty good at also maintaining the debugflags, but that's out of scope here.

So something like

#ifdef HAVE_CONFIG_H

#include "config.h"

#else

#error Please run WHATEVER_OUR_CONFIG_GENERATOR IS first

#endif

Which would fit nicely in either sq.h, or more appropriately probably in sqConfig.h

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

The point is, Tobias, that the flag must de defined on the command line, that some flags must be defined in the command line.

Further, the architectural pic t is that C headers are white box. They cannot provide encapsulation. Therefore when one includes a C header one is including implementation as well as API. Therefore, if one is only to see API one should not attempt to modify those headers prior to their inclusion other than by platform aprtoced Flags, such as _GNU_SOURCE, since otherwise one risks alteration in a way that will break later when the C header is modified.

This is exactly the case with my having to redefine the stellar define so that it avoided breaking a specific platform’s implementation of the redirect from abstract file offsets (ftell) to concrete 64-bit offsets.

The point is that architecturally a C file that is part of an application is compiled within an environment provided by a platform (different versions of macOS, Linux, Windows, etc, with different processors, etc) and that config.h serves not to alter that environment, but to provide ab abstract definition of the facilities provided by that platform. Therefore it is completely backwards to use config.h in any way to alter system includes. config.h tells one what is inside without having to look. configure does (expensive slow) black box testing on them to derive config.h. config.g is designed to inform the program of the facilities provided by the includes, not to be abused to modify those includes.

Therefore, the correct way to select between different alternatives a specific platform provides (32-bit vs 64-bit, c99 vs C11 vs C18, POSIX vs GNU, etc, is external to the source code. That means on the command line, issues either from a build environment or makefiles.

So given that one must and should use command line selection of alternatives can we please Adams in this idea of including our own header before everything else? C/C++/Objective-C etc are not designed to be written or compiled in this way.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

If you insist, go forwad.
But please note that this obsoletes half the autoconf stuff and requires manual maintainance of the thus found environmental circumstances.

I'd rather minimize the points that needs jiggiling to make things work. That's why I put work into making the autoconf stuff do their thing again, not because I like it.

That said, this is only a commit commentary, so more of a note of potential pitfallery, not an "erhobener Zeigefinger"/no an "thou shalt do it that way" :)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

David, with respect, I am currently trying to deploy an extremely complex Squeak application that includes C++, Objective-C, and mixed C++/Objective-C plugin code, threads, etc, on both MacOS and Windows. I am not trying to defeat autoconf or anything. I am trying to get the VM to compile. Trying to clean up inconsistencies, and breakages, so that our company can deploy a product and does not fail. I don't have time to suffer major disturbances in the VM code right now. Please Tobias, if you want to include config.h in front of ever file go ahead, but do it on a branch. I will note that only some projects take this approach, and many complex ones include config.h after system headers. And that this approach makes sense.

A given platform's headers provide an API, alas as a white box
Because the only guaranteed input to a platform's headers is compiler command-line switches, variations on the platform API, expressed through the system headers, are selected on the compiler command line (e.g. _GNU_SOURCE, POSIX, etc).

A config.h file from autoconf is a synopsis of a given variation of the system headers, defining to the program what facilities are available, without the rest of the program having to manually determine (often impossible at run-time, often hard to do so at compile-time). It is a communication to the program, not a communication to the headers.

This isn't me being obstructive or trying to sabotage config.h or autoconf. It is the architectural reality of C/C++/Objective-C, is it not?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.