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

Vsp3.34.0 Build Modifications #269

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

jrwelstead
Copy link

Build on Ubuntu 22 fails with LibXML error. Found that removing --disable-shared form *LibXml2.cmake resolves this issue. Also discovered and resolved in same way by Irian O. When testing, need to execute setUpClass() to ensure test_outputs document is generated if it does not exist, and resolved API testing error for two variables that do not exist.

Pip dependency was added for environment setup as setup process will fail on a clean, out-of-the-box system that has never used pip previously.

Jason Welstead added 3 commits June 22, 2023 14:36
Two variables appear to be missing from Python API and have been
commented out.  If test_outputs directory does not exist, the exception
will be thrown.  Adding. t.setupcls() forces directory to be created if
one does not exist.
@ramcdona
Copy link
Contributor

I commented on these commits directly (before you made this pull request). I'm not sure how to access those comments from here, I will copy/paste them in (with some more added comments)....

Change 1:

The preferred way to build on Ubuntu is to use the system installed version of LibXML2. I.e. this (LibXML2) should never be built.

https://github.com/OpenVSP/OpenVSP/blob/main/.github/workflows/build.yml#L77

Although Ubuntu prefers to install libraries like this built as shared libs, OpenVSP as a policy avoids shared libs when we build libraries ourselves.

You can't change something like a build option to a library without testing it on all three platforms. I promise that this change will break Windows and MacOS builds.

Change 2:
This test is hugely fragile. The list of enums is hard-coded from whenever this test was created (long ago and far away). Since removed enums like these throw errors, but there are tons of newly added enums that are not checked -- with no errors issued.

We should either 1) modify the build system to auto-generate this part of test.py such that all enums are included in the test (sounds unrealistic). Or 2) reduce this portion of the test down to a few key enums to prove that enums in general are coming through.

Change 3: No comment.

@jrwelstead
Copy link
Author

jrwelstead commented Jun 28, 2023 via email

@ramcdona
Copy link
Contributor

When you tested the changed build system on Windows, did you delete the CMake Cache (i.e. start over clean?). Sometimes some of these settings can be difficult to 'take root'.

If the flag works the way it should, it should have forced all platforms to build shared libraries for LibXML2 -- which then means that it would not be statically linked into the executable. Nothing should change on Linux (because it already uses shared libraries when you use the system installed lib) On Windows, you should notice this because 1) the executable gets smaller (LibXML2 is now dynamic (outside) rather than static (inside the executable)) and 2) it won't run on a computer that doesn't have the LibXML2 dynamic library in a place it can be found (it may already be on many computers, so this might in fact be a difficult failure to detect).

BTW, is Irian distributing the LibXML2 *.so dynamic library to the computers that he is targeting? If he isn't statically linking -- and he isn't counting on the system-installed library -- then he needs to be distributing the library himself.

LibXML2 is so common in the Linux world that I suspect all the computers he is targeting already have it installed and this exercise is a big waste of time.

What error does having the option set cause? I believe we're shipping a fairly old LibXML2 library and it is likely that the static lib build is simply broken on Linux because nobody ever uses it.

Re 2) I would happily accept a patch that deleted most of the enums from the test.py. I think it makes sense to leave a handful of core ones that won't ever go away -- just to test that SWIG and everything are succeeding in creating them and passing them through. However, I don't think we should attempt to have an exhaustive list there unless we figure out a way to auto-generate it.

If you need some simple test to check that the API is available and working, I recommend you write one.

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

Successfully merging this pull request may close these issues.

None yet

2 participants