OSDev.org

bluemoon wrote:

muazzam wrote:

Combuster wrote:"simple" shell scripts don't reduce compiling 400kloc to the set that actually changed.

But real programmers should use them. If they want to automate this process they should write their own utilities.

I think it's clear that we have different idea on what a real (or good) programmer is.
Anyway, I don't even consider writing own tool is a need, but it should be a decision if that align to your goal. For me, I don't write that tool since I want to be focus to what matter to me, especially if I don't even have the time to afford one hobby OS; but for other if they do it for fun, and found writing a tool interesting, go ahead - but unless he was doing it for no reason, it has nothing to do with the judging of programmer.

by the way, I use some shell script to do sanity checks and generate Makefile, but the shell script itself is minimal code (600 lines including the Makefile template).

Code: Select all

SLOC	Directory	SLOC-by-Language (Sorted)
6904    usr             ansic=2499,asm=2342,cpp=1537,sh=526
74      test            sh=74
0       project         (none)


Totals grouped by language (dominant language first):
ansic:         2499 (35.81%)
asm:           2342 (33.56%)
cpp:           1537 (22.03%)
sh:             600 (8.60%)

What tool did you use to generate those statistics?

All of my projects are set up like MSVC projects; a main solution directory with a makefile that builds projects in subdirectories. For Fat12/16 compatibility, I use file and directory names that are 8.3 format. (always a verb that tells what the project/solution does) eg. The only exception to this are the tools that I'm making for a custom console, where all the solutions are placed into a workspace directory because there are so many tools. (the naming scheme is still the same though). I have 13 different utilities just for manipulating data ('Filter' which works like grep, 'Graft' which works like 'dd', 'Compare' and 'Contrast', etc.)

Two of the tools in my 'Develop' solution are dependent on the 'Tokenize' data tool, and another two are dependent on the 'Archive' file tool. The 'Archive' tool is dependent on the 'Cipher' and 'Pack' data tools. So to build my toolchain, I need to recursively build at least 4 of the projects between 2 solutions in my console's workspace directory first. Some of the tools are unfinished though, and I don't want to install them into my /bin directory. The only option is to cross reference my toolchain's solution with my console's workspace solutions, otherwise I'll have to manually copy the libraries and headers each and every time I make a change. Recursive building is necessary in my case.

Recursive building is absolutely necessary for enormous projects.

No one says recursive building is unnecessary. The point was that recursive make files are.

There are better alternatives to recursive make that are better suited for the development of large scale software. It is also not at all necessary. To build our software, for example, we just run a build utility which scans and builds the source tree in one pass in the correct order and only what needs to be built. The utility is configurable and calls make on each projects make file. No recursive make files anywhere.

DaemonR wrote:Wtf does this have to do with anything? All I said is that timing a 5-line makefile does nothing to show how fast a makefile that's several hundred lines long is. Your example is meaningless. Moreover, your 5-line makefiles are most likely completely unmaintainable.

That's fallacy after fallacy after fallacy.

a 5-line makefile does nothing to show how fast a makefile that's several hundred lines long is

Hidden argument: the size of the makefile is statistically completely unrelated to it's execution time.
Observe 1: The size of a makefile is statistically proportional to the size of the project.
Observe 2: The size of the project is statistically proportional to the compilation time.
Conclusion: The time to execute a makefile is statistically proportional to it's size.
Fallacy: Non-sequiteur, possibly a faulty generalisation.
Informal response: Prove it.

timing a 5-line makefile

Argument: There are test results for a 5-line makefile
Fact: The makefile used in the presented experiment was 4767 lines total.
Fallacy: Red herring
Informal response: learn to read.

Your example is meaningless.

Fallacy: Denial fallacy and weak inference on it's own, or a hasty generalization if meant as a conclusion.
Informal response: I demonstrated that makefiles are significantly faster than one common alternative. The relevance of that is to be decided by the reader, it's certainly not to be dictated by you.

your 5-line makefiles

Fallacy: Ad hominem
Informal response: Don't feed the troll

5-line makefiles are most likely completely unmaintainable.

Fallacies: Argument from personal incredulity, appeal to probability.
Informal response: They serve me well. Define "unmaintainable".

@Combuster, I have a lot I could reply, but I'm in a good mood today so I'm just gonna leave it at that. Besides, my goal was to show there were reasons a person would want to create a custom build system, not to demonify makefiles.

EDIT:
I'm sorry for going AWOL on you btw. Last few days have been frustrating and I vented.