Waji's Standards

[Wajideu]

There are several problems I'm seeing with your code:

• You're using 4 different files to handle everything. One of the main points of this was to make a tool that didn't pollute the source directory with a bunch of crap.
• I don't think that "ifndef $(_MAKE_PP_)" would make it Make compatible. I'm pretty sure GNU Make does semantical checking of the entire file before it executes anything. It'll probably throw an error about incorrect formatting before it even parses this block.
• The "ifeq ($(MAKECMDGOALS), config)" and "-include $(CONFIG_FILE)" lines are very hackish.
• If make++ is incompatible with make, why try so hard to implement workarounds for the shortcomings of make? Why not just focus on making the language simple and implementing the features we desire, then using 'plan' to convert that (along with the configuration) into a Makefile? You seem deadset on not wanting to have a Planfile, but in the process of trying to avoid it you're having to add a bunch of other files and hackish workarounds.

There are several cases in which a person would need to build a project in multiple stages. For example, they may need to build tools to build a part of themselves, the user may be performing a Canadian cross compilation, or another example being something like binutils/gcc where you have to build both first in order to compile the C runtime and rebuild them a second time to link against it.

If make already handles it natively so would make++.

Make doesn't handle it natively. Sure, you can go the long route with the hassle of keeping track of the programs built, touching files, and executing shell scripts inbetween stages, but I figured we could probably find a way to avoid that hassle by adding in a plan/step/rule process which would allow you to encapsulate all the rules for a particular target in one block. Eg.

Code: Select all

::$(PROJECT1):
{
    :Step1:
    {
        all:
            @echo building all
        clean:
            @echo cleaning all
    }

    .c.o:
    {
        $(CC) $(CFLAGS) -c -o $@ $<
    }
}


::$(PROJECT2):
{
    :Step1:
    {
        all:
            @echo building all
        clean:
            @echo cleaning all

        .c.o:
        {
            $(CC) $(CFLAGS) -c -o $@ $<
        }
    }

    :Step2:
    {
        all:
            @echo building all
        clean:
            @echo cleaning all

        .c.o:
        {
            $(CC) $(CFLAGS) -c -o $@ $<
            $(OBJCOPY) -F binary $@
        }
    }
}

Both projects can now have different rules for the same targets.


I've begun working on this already btw. I'll put the source up on git once I get a little further along. I'm using flex/bison as well.

[b.zaar]

There are several problems I'm seeing with your code:

• You're using 4 different files to handle everything. One of the main points of this was to make a tool that didn't pollute the source directory with a bunch of crap.

As opposed to how many for autotools with configure.ac to configure and makefile.am to makefile.in to makefile.
The autoconfig.mk is a system file included with make++ so it's not listed in the project directory. You don't worry about including stdio on a regular basis.

[*] I don't think that "ifndef $(_MAKE_PP_)" would make it Make compatible. I'm pretty sure GNU Make does semantical checking of the entire file before it executes anything. It'll probably throw an error about incorrect formatting before it even parses this block.

A simple test shows...

Code: Select all

ifndef __THIS_HERE__
$(error nope)
endif

all:{

ah what?

}

It dies exactly where I expected it to.

[*] The "ifeq ($(MAKECMDGOALS), config)" and "-include $(CONFIG_FILE)" lines are very hackish.

This is valid make commands directly from the GNU manual, the example was to not include .d files when running make clean, but with the initial check for __MAKE_PP__ then this could be neatened up into native make++ code.

[*] If make++ is incompatible with make, why try so hard to implement workarounds for the shortcomings of make? Why not just focus on making the language simple and implementing the features we desire, then using 'plan' to convert that (along with the configuration) into a Makefile? You seem deadset on no wanting to have a Planfile, but in the process of trying to avoid it you're having to add a bunch of other files and hackish workarounds.[/list]

It's the same way C++ extends C. The basics of make are solid or it wouldn't still be around. It's just not exactly natural to switch from any other programming language to make or we would all be able to use it as easily as C. I actually find asm more natural than make sometimes.

Also the hacks that include 2 extra files are to replace autotools so if you weren't previously using autotools you won't need these hacks.

Make doesn't handle it natively.

Make must handle it in some way or you wouldn't be using make to build it.

[Wajideu]

[*] If make++ is incompatible with make, why try so hard to implement workarounds for the shortcomings of make? Why not just focus on making the language simple and implementing the features we desire, then using 'plan' to convert that (along with the configuration) into a Makefile? You seem deadset on no wanting to have a Planfile, but in the process of trying to avoid it you're having to add a bunch of other files and hackish workarounds.[/list]

It's the same way C++ extends C. The basics of make are solid or it wouldn't still be around. It's just not exactly natural to switch from any other programming language to make or we would all be able to use it as easily as C. I actually find asm more natural than make sometimes.

Not entirely. C code can still interact with C++ code by having the C++ expose an interface to it; or by manually mangling the symbol names. Make++ syntax is simply not compatible with Make in any way. As I stated originally, I don't want to replace make, I want to supplement it.

Make doesn't handle it natively.

Make must handle it in some way or you wouldn't be using make to build it.

The way I'm doing it requires having the makefile re-execute itself with specific options in order to build certain targets so that variables and rules can be encapsulated. I already posted an example before of how it would be done in make, and it's a tedious process. Just because it's technically possible through some complicated technique doesn't mean we shouldn't provide an interface for it. With that kind of mindset, we'd all still be writing programs in assembly code. Abstraction is always better.

[b.zaar]

The way I'm doing it requires having the makefile re-execute itself with specific options in order to build certain targets so that variables and rules can be encapsulated.

You haven't fixed anything... I can already hand code recursive make.

[Wajideu]

The way I'm doing it requires having the makefile re-execute itself with specific options in order to build certain targets so that variables and rules can be encapsulated.

You haven't fixed anything... I can already hand code recursive make.

The point is that you won't have to. You could hand-code an entire 3d graphics library in x86 assembly, but it doesn't mean you should when you can have a layer of abstraction like OpenGL hide it from you. You also cannot expect everyone to have the same skill level as you. Someone out there is going to face these problems and spend hours digging through manuals or trying to explain what it is they're trying to accomplish to some person who just doesn't get it.

I'm not really understanding why you are specifically choosing to take the more difficult route. This feels like an accurate description of our discussion at the moment:

[b.zaar]

C code can still interact with C++ code by having the C++ expose an interface to it; or by manually mangling the symbol names. Make++ syntax is simply not compatible with Make in any way.

Well you can't parse C++ code in a C compiler and expect a valid executable as output so it is similar to make++ extending make. The difference is C++ doesn't compile to C then asm which is what you are trying to do. I would like to see make++ read, interpret and execute the Makefile, no lower layers. You edit the source Makefile and run.

If we call the build files Makefile.m++ would that help?

make++ would scan for Makefile.m++, makefile.m++, Makefile, makefile. There's just no 2nd layer to a Makefile.m++ file, it's the 1st and only layer. If there's no .m++ file extension make++ wouldn't even define the __MAKE_PP__ variable and act as a pure make build.

You could hand-code an entire 3d graphics library in x86 assembly, but it doesn't mean you should when you can have a layer of abstraction like OpenGL hide it from you.

Your solution is to treat make as assembly and we must work on top of it. My idea is that make is higher than assembly, it's not the language you compile down to, it's the laguage you work with directly.

[Wajideu]

Your solution is to treat make as assembly and we must work on top of it. My idea is that make is higher than assembly, it's not the language you compile down to, it's the laguage you work with directly.

And that's why we're getting nowhere. I don't want to work with Make directly, because writing a tool that replaces it isn't my intention. I'm wanting to write a tool that specifically only configures the project, not building it.

---------------------------------------------------------------------------------

Waji's Computation Model

I wasn't joking when I said I'm ghetto-level OCD. I spent a ridiculous amount of time researching too much stuff to list just to create a model for computation that accomodates not only the compilation of source code into machine and how it's executed, but also how the human thought process works.

And in case you're wondering, yes. I did purposefully select terms that are the same exact length in spelling. Thesaurus.com floods my browser history. Would probably be good for my health if I stopped using a monospaced font while thinking up ideas.


Anyhow, this is more like a display of my own research rather than a suggestion for a standard. Perhaps some people interested in compiler development may find this useful.


Computation Overview

Code: Select all

computation
 +- parsing
 |  +- tokening
 |  |   +- scanning         scanning data for patterns
 |  |   +- matching         matching patterns with lexemes
 |  |   '- evaluating       evaluating lexeme definitions
 |  '- glossing
 |      +- deducing         deducing the syntax of the definitions
 |      +- refining         refining how to deduce the syntax
 |      '- explaining       explaining what has been deduced
 +- reading
 |   '- optimizing          optimizing the explanation
 +- writing
 |   +- generating          generating thoughts from an explanation
 |   +- assembling          assembling thoughts together
 |   '- formatting          formatting thoughts into an idea
 +- linking
 |   +- finalizing          finalizing an idea as a memory
 |   +- extracting          extracting information from a memory
 |   +- converting          converting the information
 |   '- inspecting          inspecting the information
 '- loading
     +- allocating          allocating a way to process the information
     +- relocating          relocating the information
     '- processing          processing the information

Computation Pipeline

Code: Select all

                               .------------.
                               v            |
[DATA] --(1)--> scanning -> matching -> evaluating --.
                   ^           |                     |
                   '-----------'                    (2)
                                                     |
.-----> explaining <- refining <- deducing <---------'
|     '     |            |           ^
|     '     v            '-----------'
| (4) ' optimizing
|     '     |
|     '     v
'------ generating
            |
            v
        [THOUGHTS] <------.
            |             |
            |     (5)     |
            v             |
        assembling -> formatting -> [IDEA] -> finalizing
                          ^                       |
                          |                       v
                          |          (6)       [MEMORY]
                          |                       |
                          |                       |
        inspecting <- converting <- extracting <--'
            |
           (3)
            |
            v
        allocating -> relocating -> processing -> [ACTION]
            ^                           |
            '---------------------------'


Indication Key:

	(1) Tokening Data
	(2) Glossing Data
	(3) Applying Data

	(4) Thinking Loop
	(5) Planning Loop
	(6) Learning Loop


Development Key:

	data       = source code
	thought    = assembly code
	idea       = machine code
	memory     = object file
	action     = code execution

	scanning   = scanning part of lexical analyzer
	matching   = matching lexemes to regular expressions
	evaluating = evaluating part of lexical analyzer
	deducing   = generating abstract syntax tree (AST)
	refining   = pre-processing
	explaining = generating abstract semantic graph (ASG)
	optimizing = optimizing ASG
	generating = generating assembly code from ASG
	assembling = assembling assembly code into machine code
	formatting = placing machine code into object files
	finalizing = converting object file into final format
	extracting = extracting sections of object file
	converting = converting sections into something usable
	inspecting = inspecting the content of the sections
	allocating = allocating space for the code
	relocating = moving code into RAM and fixing pointers
	processing = executing the code

[b.zaar]

I don't want to work with Make directly, because writing a tool that replaces it isn't my intention. I'm wanting to write a tool that specifically only configures the project, not building it.

You're right of course we should build on top of things like Windows did with dos, 386 did with 8086 and vbe 2 did with vbe 1.

You have a vision I didn't at first appreciate.

[Candy]

Can I ask you to take a step back from making the actual tool?

What is it going to do for you? Why are you thinking about making it; what functionality will it fulfill that would be missing if you just cut it out? What other solutions exist to fit in there and why do you disqualify them? What differentiates your solution from the others that makes it more viable / usable for you, and which of those reasons could also apply to others? What's the minimal design for your new tool that satisfies those differentiations and that does that functionality?

After you have those questions answered I think you'll have a better design for your tool and you will have a much easier time selling it to others.

[Wajideu]

Can I ask you to take a step back from making the actual tool?

What is it going to do for you? Why are you thinking about making it; what functionality will it fulfill that would be missing if you just cut it out? What other solutions exist to fit in there and why do you disqualify them? What differentiates your solution from the others that makes it more viable / usable for you, and which of those reasons could also apply to others? What's the minimal design for your new tool that satisfies those differentiations and that does that functionality?

After you have those questions answered I think you'll have a better design for your tool and you will have a much easier time selling it to others.

I've already answered all these questions numerous times; but again (sigh):

What is it going to do for you?

Manage the configuration of projects; generating Makefiles.

Why are you thinking about making it; what functionality will it fulfill that would be missing if you just cut it out? What other solutions exist to fit in there and why do you disqualify them?

Because autotools (the only other tool that does the job I need) is very difficult to port. It's also difficult to manage, it's slow, it heavily pollutes the project directory, doesn't play nicely with traditional Makefiles, the way that it checks for language features is very shoddy, it doesn't cache settings well, and every time there's a minor revision to the codebase of autotools the developer has to re-update their autotools installation and the installation of all of it's dependencies; otherwise they can't build the project.

What differentiates your solution from the others that makes it more viable / usable for you, and which of those reasons could also apply to others?

Briefly, the idea is to address all the aforementioned problems autotools has. It doesn't apply to any other build utilities because there are no other build utilities that provide the same amount of extensive checking and configuration as autotools.

What's the minimal design for your new tool that satisfies those differentiations and that does that functionality?

As I stated in my quite a few times, the minimal design is simply a tool which converts a Planfile into a Makefile based upon the detected programs, headers, and available functions; and the configured options and features. The Makefile itself being a sort of cache of the configuration process. Instead of 'configure; make'; you 'plan; make'. The user can even distribute generic Makefiles alongside the Planfiles to ease the transition, and Planfiles themselves are targets of the Makefiles; which ensures that the project is automatically reconfigured every time the Planfile is changed.

[Brendan]

Hi,

As I stated in my quite a few times, the minimal design is simply a tool which converts a Planfile into a Makefile based upon the detected programs, headers, and available functions; and the configured options and features. The Makefile itself being a sort of cache of the configuration process. Instead of 'configure; make'; you 'plan; make'. The user can even distribute generic Makefiles alongside the Planfiles to ease the transition, and Planfiles themselves are targets of the Makefiles; which ensures that the project is automatically reconfigured every time the Planfile is changed.

So... You need 'make' because the tool-chain sucks and (e.g.) the compiler/linker won't simply skip unnecessary work by itself; and you need plan files (or auto-tools) because the tool-chain sucks and portable projects aren't possible. Soon, you're going to want something to manage/generate plan files; because the new layer of work-arounds (for the older layer of work-arounds, for the even older layers of work-arounds) needs more work-arounds.

At which point does it make sense to do root cause analysis, and fix the actual underlying problems with languages/compilers; such that this hideous parade of puke is no longer necessary?


Cheers,

Brendan

[Candy]

At which point does it make sense to do root cause analysis, and fix the actual underlying problems with languages/compilers; such that this hideous parade of puke is no longer necessary?

Although I do think that figuring out what to build, and actually building it are two separate steps, I also don't understand why everybody seems to want to build on top of Make.

[Brendan]

Hi,

At which point does it make sense to do root cause analysis, and fix the actual underlying problems with languages/compilers; such that this hideous parade of puke is no longer necessary?

Although I do think that figuring out what to build, and actually building it are two separate steps, I also don't understand why everybody seems to want to build on top of Make.

A compiler has to figure out which files are needed and already knows what the output file will be; so it's simple to get the compiler to check if the output file/s are newer than the input file/s and do nothing if nothing needs to be done. That way you can just have a very basic "do everything" script and let the tools skip whatever wasn't necessary.

Note: For C/C++ this is slightly less convenient, because C/C++ allow you to spread "#include" directives all over the place, which means that it's "less simple" for a C/C++ compiler to quickly determine which files are needed (without pre-processing almost every file first). Better languages may be better.


Cheers,

Brendan

[Wajideu]

I get the feeling from a lot of people's comments that most people here have little to no experience using autotools aside from typing 'configure' before they make an open source project they've downloaded. Likely due to the bubble of hate surrounding it, where people just unquestionably avoid it and bash it for no more than hearsay what they know about it.

I'm not really good at explaining things, so for those people I'd suggest picking up a book or two like I did to learn how autotools works; and both the benefits and drawbacks of using it. Makefiles are perfect for the job they're intended for. It's not broken, so I don't want to fix it. Autotools on the other hand is a must for a truly portable project, but it's clunky and there are many problems you'll be faced with when using it. The 'plan' project is supposed to address those problems and produce a more lightweight solution.


EDIT:
So Im a bit aggravated, I haven't been able to get Qemu or VirtualBox to work since I upgraded to Windows 10. I think I'm going to install Arch-Linux alongside it. Gonna have to use Ubuntu as a stepping stone though, because I don't have any more blank cd's and my thumbdrive is missing.

-------------

WHAT THE HELL.

So, I just tried building an autotools project for the first time in Linux. It configured in less than a second. Usually that takes about 2-3 minutes in Windows. Mind = blown.

Well, from now on I'm just going to do all of my development on Linux. Will save me a buttload of time.

[b.zaar]

So I found this What’s Wrong With GNU make?

And I'm just gonna leave something attached. Feel free to laugh at it then maybe test it on your unix versions. I'm sure it could be improved...