Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

errors: make it easier for cross-compilation #2814

Open
markus2330 opened this issue Jun 27, 2019 · 7 comments

Comments

Projects
None yet
4 participants
@markus2330
Copy link
Contributor

commented Jun 27, 2019

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 markus2330 added this to the 0.8.27 milestone Jun 27, 2019

@markus2330

This comment has been minimized.

Copy link
Contributor Author

commented Jun 27, 2019

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

@haraldg

This comment has been minimized.

Copy link

commented Jun 27, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Jun 27, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jun 27, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Jun 28, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jun 28, 2019

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.

@Piankero

This comment has been minimized.

Copy link
Contributor

commented Jun 28, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.