OSDev.org

• 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.

b.zaar wrote:

Wajideu wrote: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++.

::$(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 $@
        }
    }
}

Wajideu wrote: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.

Wajideu wrote:[*] 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.

ifndef __THIS_HERE__
$(error nope)
endif

all:{

ah what?

}

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

Wajideu wrote:[*] 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]

Wajideu wrote:Make doesn't handle it natively.

b.zaar wrote:

Wajideu wrote:[*] 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.

b.zaar wrote:

Wajideu wrote:Make doesn't handle it natively.

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

Wajideu wrote: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.

b.zaar wrote:

Wajideu wrote: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 wrote: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.

Wajideu wrote: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.

b.zaar wrote: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.

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

                               .------------.
                               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

Wajideu wrote: 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.

Candy wrote: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.

Candy wrote:What is it going to do for you?

Candy wrote: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?

Candy wrote: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?

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

Wajideu wrote: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 wrote: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?

Candy wrote:

Brendan wrote: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.