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

Include required libraries in repository #137

Open
Quaker762 opened this issue Jan 7, 2019 · 4 comments
Open

Include required libraries in repository #137

Quaker762 opened this issue Jan 7, 2019 · 4 comments

Comments

@Quaker762
Copy link
Member

Considering the issue that has been raised in #136, I propose that we control what version of the libraries we have by either including them as submodules, or the source code themselves, similar to which can be found in this project: https://github.com/xoreos/xoreos.

We could then have targeted build scripts (similar to build.bat or build.sh) that would build the required libraries and put them in a lib folder, which we then link against. This should help homogenise building and prevent per platform errors that Windows users (which I assume most normal developers are running day to day) seem to be having. We won't have to rely on strange cmake hacks either.

@z33ky
Copy link
Collaborator

z33ky commented Jan 7, 2019

We can add this as a build-option toggle. I don't see why we should write system-specific scripts for this.

Generally I like allowing a diverse setup. Especially allowing and at least half-heartedly supporting using system-installed libraries; I always find it annoying when projects begin by fetching some libraries and compiling their own version, although it seems to be the popular thing (see Rust/Cargo for example).
I agree that it'd be good to automatically fetch and build "known good" versions for people who don't care or prefer this approach though.

A second step, though orthogonal to this goal, would be fully specifying a build environment via Nix or Docker or something.

@Quaker762
Copy link
Member Author

We can add this as a build-option toggle.

How do you mean?

Generally I like allowing a diverse setup. Especially allowing and at least half-heartedly supporting using system-installed libraries; I always find it annoying when projects begin by fetching some libraries and compiling their own version, although it seems to be the popular thing (see Rust/Cargo for example).
I agree that it'd be good to automatically fetch and build "known good" versions for people who don't care or prefer this approach though.

Yeah I guess it's Windows that's the real PITAS here for the most part, especially libraries where you're forced to use an MS toolchain unless you compile them yourself (I'm looking at you, GLEW). I'll the decision on whether or not to do this up to you, though.

@z33ky
Copy link
Collaborator

z33ky commented Jan 7, 2019

How do you mean?

We add an option to our build-system, e.g. like our current ASSERTION_BEHAVIOR variable we can have one USE_SYSTEM_LIBRARIES. We could even get fine-grained have have a USE_SYSTEM_$LIB for each library we use. I don't know if that's useful though.

especially libraries where you're forced to use an MS toolchain unless you compile them yourself

I think that's only the case with C++ though, because C++ does not have a standardized ABI.
clang++ and g++ are only able to cooperate because clang chose to imitate g++, which is able to define the quasi-standard ABI because it is the popular kid in Linux town (and more).
This breaks down if you try to swap out libstdc++ with libc++ though (I've tried), then you also need to compile all C++ dependencies yourself. Well, technically only those that use the standard library.

I'll the decision on whether or not to do this up to you, though.

This is definitely a good idea. I'm unsure however what the default setting should be.

@Quaker762
Copy link
Member Author

Quaker762 commented Jan 8, 2019

We add an option to our build-system, e.g. like our current ASSERTION_BEHAVIOR variable we can have one USE_SYSTEM_LIBRARIES. We could even get fine-grained have have a USE_SYSTEM_$LIB for each library we use. I don't know if that's useful though.

I reckon just having one that chooses between a local or system-wide copy would definitely enough. You either gather the libs yourself (via submodule) or use something from a package manager.

I think that's only the case with C++ though, because C++ does not have a standardized ABI.
clang++ and g++ are only able to cooperate because clang chose to imitate g++, which is able to define the quasi-standard ABI because it is the popular kid in Linux town (and more).
This breaks down if you try to swap out libstdc++ with libc++ though (I've tried), then you also need to compile all C++ dependencies yourself. Well, technically only those that use the standard library.

Yeah, I suppose this the unfortunate outcome of multiple compilers existing with different ABIs/standards.

This is definitely a good idea. I'm unsure however what the default setting should be.

Personally, I'd prefer submodules/local libraries so that we don't get anymore of these build questions. I think the last issue opened was the third or fourth one? I definitely feel this is creating a barrier for most normal C++ programmers that use Windows etc that don't have the need for a Linux system. Plus for this type of programming, I'd much rather control the version of the lirbaries we use, so that if something breaks (coughcmake and SDL cough), we can continue development.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants