errors: make it easier for cross-compilation

[markus2330]

As we have now #2808 maybe we can also fix the errors to not need code generation with native code: then we would not need the complicated cross compilation we have now. Actually, we could simply leave our nifty C++/mustache code generation techniques and simply check-in the kdberrors.h as we already do for the man pages.

@DasRoteSkelett @haraldg What do you think?

Btw. #2808 (and this) might be breaking changes for you if you copy our tools by name.

[markus2330]

(After #2686 our errors will be very stable and the file would hardly change.)

[haraldg]

I have no strong opinion. If I understand you right, then you propose that we get rid of the stage where we build elektra on the host system first, before building on the target? I think we will need the host build anyway, because we probably need at least kdb for building applications depending on libelektra, so not terribly much to gain here.

Actually, after my recent insights into mounting and the impossibility to use elektra in a non-global way, I'm already dreading the task to package an elektrified application for a cross compilation distribution. Unfortunately I don't have enough time to look into this now.

[markus2330]

I think we will need the host build anyway

Yes, you are right, for building applications with code-generation or with mounting you need it anyway. But we could drop the INSTALL_BUILD_TOOLS (as this would not be needed anymore).

Actually, after my recent insights into mounting and the impossibility to use elektra in a non-global way, I'm already dreading the task to package an elektrified application for a cross compilation distribution.

Yes, in cross-compilation distribution it will be tricky. I hope we can help you there.

[kodebach]

Using CMake functions to generate kdberrors.h has the disadvantage that we need to call CMake again, if the error specification changes. But since #2686 is merged now that should be too much of a problem.

Actually, we could simply leave our nifty C++/mustache code generation techniques and simply check-in the kdberrors.h as we already do for the man pages.

Checking in generated code is kind of bad practice. If we use a mustache template the C++ code should be pretty small. If C++ is problem there is lots of different implementations of mustache, including one in C.

We could (probably) also do a pretty simple solution in pure CMake. Instead of a single header, we generate one header for each error type using a simple configure_file template. And then we generate kdberrors.h as simply a few #include lines referencing the other files. Although CMake is also written in C++, so not sure how that would be different from a simple mustache template and C++ generator.

[markus2330]

It is a nifty idea to generate one file per error code and (compiled) language. As we have now very few errors it should be feasible. Let us see how @Piankero will support the errors in Java. Later we also need a solution for Go and Rust.

[kodebach]

Having multiple files is a requirement for Java (public classes), for C it doesn't matter either way, but for Go and Rust it would be uncommon to have one file per type I think.

In fact the whole one file per code thing would just be a kind of hack to simplify using CMake. Once we are talking about multiple languages, using the more flexible mustache templates certainly makes more sense.

[ghost]

Having multiple files is a requirement for Java (public classes)

That is exactly the case even though you could make nested classes which I do not prefer :)

Let us see how @Piankero will support the errors in Java

I will make the Java exceptions like the structure here where I inherit from the upper classes.

Eg.

public class PermanentException extends Exception {...}
	public class ResourceException extends PermanentException {...}
		public class MemoryAllocationException extends ResourceException {...}
	public class InstallationException extends PermanentException {...}
...

where each line is in its own file.

[markus2330]

I think we can close this now.

@DasRoteSkelett I would be interested to hear from you if you were able to use Elektra. You can also write to me by email markus@libelektra.org