A new IDE and compiler philosophy

[Rick C. Hodgin]

In developing a new IDE and general compiler philosophy, it's oc-
curred to me that I wanted a way to keep the compiler settings with
the source files, rather than having them in a project settings.

That way any compiler that was able to parse the source file could
parse the settings as well, allowing for multiple tools to be able
to work natively on the source files without having to know how to
parse a particular project file or solution (in Visual Studio).

I was wondering what people think of this?

-----
In general, it would be a block at the top (included within the
comment characters) so older compilers would simply ignore it:

/*compiler settings {
}*/

The IDE would read this section and load the input and set the
various flags and present a screen which allows those settings
to be viewed, along with all the other settings that are avail-
able. Clicking and setting things beyond their default values
would write them to that section.

The source file would maintain the settings within that block,
but the IDE wouldn't show them in the source file, but would
separate out that block and present it in its own tab or as an
option when chosen. When saving the source file back to disk,
both that block and the normal source code would be written.

In this way, the settings always go with the file. Options
are encoded for 32-bit, 64-bit compile targets, different ISAs,
different pre- and post- build events to copy input or output
files or run secondary processing, etc.

Example:

/*compiler_settings {
char = 8; // Bits
short = 16;
int = 32;
long = 64;

requires = 3.4; // Some version of a standard
code align = 16; // Paragraph alignment on code
data align = 1; // Byte alignment on data
extern = "C"; // Use unmangled exports

// Generic build settings here
build lib {
}
build dll {
}
build exe {
}

// Special settings here for 32-bit x86 code
target x86 {
build lib {
}
build dll {
}
build exe {
}
}

// Special settings here for 64-bit x86 code
target x64 {
}

// Special settings here for 32-bit ARM code
target arm-32 {
}

// Special settings here for 32-bit ARM code
target arm-64 {
}

// Et cetera
}*/

Any thoughts?

--
Rick C. Hodgin

[Mr Flibble]

Most settings are platform specific so it would be foolish to put them in
the source file and the sizes of the fundamental types aren't settings at
all but platform/hardware specific implementation details so it makes even
less sense for them to be in the source file.

A) You are trying to solve a problem with a deeply flawed solution.
B) You are trying to solve a problem that no longer exists with the advent
of CMake and such.

Makefiles have always been separate to the source files that are built and
with good reason: we want a separation of concerns separating WHAT we are
building from HOW we are building it.

/Flibble

--
“You won’t burn in hell. But be nice anyway.” – Ricky Gervais

“I see Atheists are fighting and killing each other again, over who
doesn’t believe in any God the most. Oh, no..wait.. that never happens.” –
Ricky Gervais

"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."

[Mr Flibble]

Oh and I forgot to mention that your idea of using of comments to do such
things is egregious: we have #pragma for a reason.

[Rick C. Hodgin]

On 4/3/2019 12:21 PM, Mr Flibble wrote:
> Most settings are platform specific so it would be foolish to put them in the
> source file and the sizes of the fundamental types aren't settings at all but
> platform/hardware specific implementation details so it makes even less sense
> for them to be in the source file.

The statement of specifying the required size of each fundamental type
allows the compiler to generate a warning if the default sizes are not
those sizes.

> A) You are trying to solve a problem with a deeply flawed solution.
> B) You are trying to solve a problem that no longer exists with the advent of
> CMake and such.
>
> Makefiles have always been separate to the source files that are built and
> with good reason: we want a separation of concerns separating WHAT we are
> building from HOW we are building it.

This solution provides for a new makefile format:

file.obj: file1.cpp file2.cpp file3.cpp
data.obj: data1.cpp data2.cpp

file.exe: file.obj data.obj

The developer goes to a single source location to edit their code and
settings (the IDE provides it for them).

Much simpler.

--
Rick C. Hodgin

[Rick C. Hodgin]

On 4/3/2019 12:24 PM, Mr Flibble wrote:
> Oh and I forgot to mention that your idea of using of comments to do such
> things is egregious: we have #pragma for a reason.

I don't know of an efficient way to do a multi-line #pragma. And I'm
not particularly keen in having a block of #pragma keywords.

In CAlive, the syntax would be:

compiler settings
{
// Settings here
}

linker settings
{
// Settings here
}

I suggest the commented /*compiler settings {..} linker settings {..}*/
syntax for backward compatibility for those systems that still use legacy
CMake builders, for example.

--
Rick C. Hodgin

[Mr Flibble]

On 03/04/2019 18:18, Rick C. Hodgin wrote:
> On 4/3/2019 12:24 PM, Mr Flibble wrote:
>> Oh and I forgot to mention that your idea of using of comments to do
>> such things is egregious: we have #pragma for a reason.
>
> I don't know of an efficient way to do a multi-line #pragma.  And I'm
> not particularly keen in having a block of #pragma keywords.
>
> In CAlive, the syntax would be:
>
>     compiler settings
>     {
>         // Settings here
>     }
>
>     linker settings
>     {
>         // Settings here
>     }

cares
{
nobody

[Ian Collins]

On 04/04/2019 06:09, Rick C. Hodgin wrote:
> On 4/3/2019 12:21 PM, Mr Flibble wrote:
>> Most settings are platform specific so it would be foolish to put them in the
>> source file and the sizes of the fundamental types aren't settings at all but
>> platform/hardware specific implementation details so it makes even less sense
>> for them to be in the source file.
>
> The statement of specifying the required size of each fundamental type
> allows the compiler to generate a warning if the default sizes are not
> those sizes.

*If* sizes are important, a static_assert can be used.

>> A) You are trying to solve a problem with a deeply flawed solution.
>> B) You are trying to solve a problem that no longer exists with the advent of
>> CMake and such.
>>
>> Makefiles have always been separate to the source files that are built and
>> with good reason: we want a separation of concerns separating WHAT we are
>> building from HOW we are building it.
>
> This solution provides for a new makefile format:
>
> file.obj: file1.cpp file2.cpp file3.cpp
> data.obj: data1.cpp data2.cpp
>
> file.exe: file.obj data.obj
>
> The developer goes to a single source location to edit their code and
> settings (the IDE provides it for them).

The makefile or equivalent is already in a single source location.

--
Ian.

[Rick C. Hodgin]

If it's auto-created by the IDE, yes. If a person has to maintain
it manually, no.

--
Rick C. Hodgin

[Mr Flibble]

LOLWUT

[Richard Damon]

On 4/3/19 1:18 PM, Rick C. Hodgin wrote:
> I don't know of an efficient way to do a multi-line #pragma.  And I'm
> not particularly keen in having a block of #pragma keywords.

_Pragma( "string"
"string2"
"stribg3")