Single source file

[iansjack]

The biggest individual reason is just the handling of multiple source files.

Not wishing to flame, but I would disagree with that. Strong reasons for build systems are (i) to allow different configurations of the same program, (ii) to allow individual parts of a program to be built. We come back to the example of gcc; different people want to build different components of gcc, with different configurations. I just don't see how you can effectively manage this with a simplistic single-file/single-compile-command system. And if you just want to compile a program without looking at the source, what does it matter if it is composed of 1 file or 1,000? The commands to build it are still the same simple trinity:

./configure
make
make install

Of course this doesn't apply to "hello world" (elegant though it is) and I think few would disagree that this is best dealt with as a single source file. But few people are content with computers that run only "hello world" (or even "goodbye cruel world").

[Antti]

I simply don't feel like wasting my time waiting for the compiler.

Are you wasting your time for waiting the actual compiling or the highly frequent starting and stopping the compiler?

If you don't believe me, try to quickly install a Linux From Scratch with a desktop and everything the average distro gives you.

An interesting topic by the way. I was using LFS few years and I had a fully-featured desktop. It surely took time. This was before I started programming. Your example is good because it underlines the problem we have with source code.

they notice that Makefiles can do a bit more.

Like handling dependencies and rebuilding only these "one hundred" source files that depends on the header file I am modifying instead of all "two hundred". It solves the problem that we do not need to have at all. Do not get me wrong, make is a lot better than script/batch files.

[Antti]

Strong reasons for build systems are...

It is possible to allow different configurations of the same program without relying on build systems. Besides, I do not think the current way is very elegant either. Giving some --enable-this-feature and --disable-this-feature flags as parameters to a 6000-line-configure script that would result in a gigantic Makefile that does more magic.

The same could be achieved, even now, by just giving parameters to the compiler directly.

Code: Select all

../configure --enable-myfeature
make

vs.

cc -o foo -DENABLE_MYFEATURE foo.c

These both are bad. It should be so that when you right-click your (single) source code file and select 'Custom build', the OS-integrated (or otherwise "not-program-specific") wizard will guide you and there are all the enables/disables listed and easily configurable. Then it is not necessary to guess what --enable-myfeatures are really available.

I agree, it is not fair to use GNU repeatedly as an example.

[bluemoon]

To avoid the need to scroll over thousands of lines, you would need some kind of index in your single source file, which I see virtual file and virtual folder in the end. It is the people like to / used to work with files; you would need some very convincing ideas (like tags) to alter people's workflow.

[iansjack]

The same could be achieved, even now, by just giving parameters to the compiler directly.

No it couldn't, not without ending up with a source file consisting of a tangled web of #ifdefs just to include or not include particular parts of the program. I like to keep that sort of complexity out of the source file(s), as far as possible, and rely on separate tools to manage the selection of what will be included in the final image. As I said before, in reality you end up with a number of programs/libraries and it does not make sense to try to produce that from a single source file.

I still haven't seen any convincing argument to abandon a method of working that works so well for so many programmers. The assertion that it is easier to distribute a single file rather than several files encapsulated in a single .tar file doesn't convince me. As an analogy it could be argued that it would be a lot simpler to have a single directory of files rather than bothering with all this tree of directories malarky.

[Antti]

which I see virtual file and virtual folder in the end.

One problem with the ordinary files is that they do not have meta-information. At least any portable way to include that. If we had a file called foo.src, it would not tell much. If we had a folder and the file inside it, like ProcessInput/foo.src, then we would have a little more information. By the way, having good and consistent names is also a thing that is often brushed aside. Of course, it is possible to add good description as a comment in the beginning of the file. However, why we need to bother to figure out also a good file name for the file?

Now, we could have this single source file and every maintainable unit, e.g. one function/method, has a meta-information header. This unit could be much smaller than we now dare to dedicate own source file. It could have several tags for helping the search of it, a reusability flag to mark portable code, dependency information (perhaps not, too heavy), a good description of what it does etc. Then we have this IDE with "a tree-like view of the program" and it is easy to see the big picture.

[Antti]

a tangled web of #ifdefs just to include or not include particular parts of the program

A real problem especially because the preprocessor of C does not interpret/understand the code. It just calmly handles lines of text. Something more intelligent must be figured out. It is a good start that modern compilers can leave out unused code. I would start looking that direction.

to abandon a method of working that works so well for so many programmers

I think it works reasonably well.

[iansjack]

Since this is a site devoted to OS design, let's take as an example of a moderately complicated program - the Linux kernel. Can you really, hand on heart, say that this could reasonably be managed, including configuration, as a single source file?

[Antti]

It is not possible. I say, hand on heart, no. This idea is more for user-space applications. All the architecture dependent things, e.g. assembly language, real need for linker magic, etc. make it too complicated.

I think we should not think a single program as big as the Linux kernel. If we look at the modules, it is already common to have "one source file, one module" philosophy. I think it is a little bit similar approach than what I was looking for. Kernel developers have apparently noticed that it is easier to have quite big units. Of course, these "big files" are not stand-alone enough. A microkernel could very well use "one service, one file" approach.

I already said that I do not want to have a word processor and Internet browser written in the same file. For the same reason, I think the kernel should not be "one executable".

[sandras]

Just FYI, suckless.org has some of it's programs written in one *.c file. Of course, these programs are several thousand lines of code - not very much. Single-source-file approach works out good for these kind of projects. I found it convenient to use simple text search for examining dwm's source code.

[Antti]

only for crappy "plain text" development environments...

I have to admit that all the ideas about having meta-information for functions/methods/units-like-these could be integrated more seamlessly into some other format than "plain text". This traditional "plain text" format gives to much freedom to do things in many ways. However, if we look at some binary format, the format is usually very strict. A conforming file must precisely follow the standard.

If we look at plain-text formats, we can see it is usually possible to have quite "ugly" content that is still valid. I am afraid that people are not willing to accept the strict conventions that would be required to elegantly implement the meta-information header. Of course, if the whole plain-text file is under the control of IDE, then it is easier.

This does not mean I "give up" and say "we cannot change anything with current tools". It looks like the full implementation really requires fundamental change in the way we consider programming, e.g. writing plain-text files and compiling them. However, in a smaller scale, I think this idea could be be taken into play right now.

[iansjack]

Sounds like SmallTalk to me.

It's been around for years but, let's face it, it's not the most popular programming environment.

[Kevin]

Are you wasting your time for waiting the actual compiling or the highly frequent starting and stopping the compiler?

Spawning processes certainly does take some time. However what you're really waiting for is still the actual compiling.

An interesting topic by the way. I was using LFS few years and I had a fully-featured desktop. It surely took time. This was before I started programming. Your example is good because it underlines the problem we have with source code.

And I can't see how giving up modularity, and therefore having to compile much more code, solves it.

Like handling dependencies and rebuilding only these "one hundred" source files that depends on the header file I am modifying instead of all "two hundred". It solves the problem that we do not need to have at all.

You mean because we could just always compile the one whole source file that was created by merging the 200 files - so we don't even have to think about compiling only the half of it because it isn't possible any more?

Besides, I do not think the current way is very elegant either. Giving some --enable-this-feature and --disable-this-feature flags as parameters to a 6000-line-configure script that would result in a gigantic Makefile that does more magic.

The same could be achieved, even now, by just giving parameters to the compiler directly.

But you do know that these 6000 lines in the configure scripts aren't all nops? A typical configure script does much more, checking which libraries and functions are available, testing for platform-dependent behaviour etc. and are an important part of making programs portable?

-D is a nice compiler switch, but it solves only a minimal part of what configure scripts are doing.

These both are bad. It should be so that when you right-click your (single) source code file and select 'Custom build', the OS-integrated (or otherwise "not-program-specific") wizard will guide you and there are all the enables/disables listed and easily configurable. Then it is not necessary to guess what --enable-myfeatures are really available.

Please leave me alone with your mouse and point-and-click impediments, I want to work efficiently.

Then we have this IDE with "a tree-like view of the program" and it is easy to see the big picture.

You've never worked on a big project, have you? Can you imagine what the tree-like view of the Linux kernel would look like? Or because you like to say that kernels are different, let's take qemu, with which I'm more familiar anyway. (And that's still the kind of projects that compile in a few minutes, not hours or days like X, KDE or LibreOffice.)

[Antti]

Are you sure that having source dependencies like this

Code: Select all

/* One of the file in src hierarchy */

#include <all.h>
#include <bar.h>

void foo()
{
	general_initialize();
	post_initialize();
	clean_up();
	bar();
}

will make that particular unit modular?

I already said that the Linux kernel is too big to be considered as a reasonable unit. KDE and LibreOffice are not "one-executable compatible". If the program is too big, then it should be splitted on smaller programs (most of them are splitted already). These units could be one single-source files. They do not have source-code-level dependencies (like the example code above) with each other.

Please leave me alone with your mouse and point-and-click impediments, I want to work efficiently.

If we had mechanism to allow that point-and-click interface, then we would also have an advanced (CLI) interface. If the "interface" is well standardised, nothing would stop doing it.

[Antti]

And yes, Kevin. Your previous post is quite tough and I could not invalidate all the points you made. It is sad that current conventions are based on the foundation that requires so much hacks to create, e.g. portable programs.