blacktoppstudios / jagati Goto Github PK
View Code? Open in Web Editor NEWA package manager (not quite but close enough) for working with parts of the Mezzanine Game Libraries.
License: GNU General Public License v3.0
A package manager (not quite but close enough) for working with parts of the Mezzanine Game Libraries.
License: GNU General Public License v3.0
We don't know exactly what this will look like but we need to expand the jagati to allow easy building of iOS apps.
Right now added to a list of headers looks something like this:
set(StaticFoundationHeaderFiles "${StaticFoundationIncludeDir}CrossPlatformExport.h" "${StaticFoundationIncludeDir}DataTypes.h" ... ) ShowList("Header Files:" "\t" "${StaticFoundationHeaderFiles}")
it should be much simple and not require duplication of data as this does. The name "StaticFoundation" prevent easily renaming the project and if it had a type it would be hard to troubleshoot. Some kind of function/macro that did this would be much easier to work with and less error prone.
This are several list of source that should kind of consolidation. Those lists should be determined and listed here.
This will likely require that issue #10 be resolved, but some users will not use a library if it does not provide a simple to install SDK.
Something like this should work:
cmake ..
make
sudo make install
and the Headers and libraries should be installed.
Add tests to make it easier to refactor with confidence. This will help make it easier to split out the Documentation because
Currently the naming scheme of test Source files requires that Files contain a class with the file name plus "Tests", so "Foo.h" must have a class "FooTests".
This encourages putting tests in a file with an identical name to the header of what they are testing.
A call to CreateCoverageTarget always creates the target if it is supported by the compiler whether or not the game dev disabled this.
The old Mezzanine has support for automatically creating exceptions. The CMake portion for this needs to be ported to the Jagati.
https://github.com/BlackToppStudios/Mezzanine/tree/master/Mezzanine/libincludes/common/exceptions
The CMake macros should be made available so any repo can generate exceptions code with it.
We should probably come up with a better concept of what the bit pattern in the exceptions is used for.
Possibly even a tool to get at human readable string from the bit pattern and remove the need for game devs to care about the bit pattern at all. If this isn't practical it should be spun off into its own ticket for tracking and the simpler version of the exception system we have now should be implemented.
This should not force the exceptions to be declare in the same namespace. Presently all exceptions are in the Mezzanine namespace. We don't want game devs adding stuff here.
The current implementation has a bunch of Java Exception conversion stuff, that needs to go elsewhere and can be omitted from this version.
The old system used file inputs, this new system cannot. It must store all its data in string directly in the Jagati or download files to use.
It should be easy for people to put their own packages into the jagati. If the packages were stored in a separate file and downloaded on it own, then people could make minimal changes to the Jagati by changing the URL to the index and providing their own.
In issue #21 I learned that several members of the Jagati API can only be tested by checking the available list of targets. We should figure out a way to that and implement those tests.
Every functions should be looked at and a ticket made for it, this is to help manage the complexity
Clang on apply was incorrectly detected as not supporting --coverage, which is what we use for coverage.
Either get all the output to follow some common format or make all the output match flat and unintended.
Add tests to make it easier to refactor with confidence. This will help make it easier to split out the Documentation because
The SHA512 of an empty file
is cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e
This is what is downloaded when using an https URL and openssl was not built it (which appears the be the default on Ubuntu).
This means adding "-s DISABLE_EXCEPTION_CATCHING=0" in the flags section. This does add significant code bloat, but the unit test suite uses exceptions. So this might be an option in the future, but for now this needs to be enabled
https://kripken.github.io/emscripten-site/docs/optimizing/Optimizing-Code.html
Sources like https://www.youtube.com/watch?v=rLopVhns4Zs&feature=youtu.be and https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/ describe how to do cmake "right".
Each CMake target has a concept of properties which can be used to handle linking, but will likely require a major upgrade to the Jagati. This should ultimately be a simplification but could be more (but more reliable) lines of code.
A timestamp should be logged when starting, after building but before linking, after linking, and after unit test execution. This will let us know how long each part is taking and provide information for planning.
In the macro AddIDEVisibility all the default files are listed and this does not include JenkinsFile which all Mezzanine Projects should have.
Check that other files are also present.
There is no good reason to leave the unspecified build unspecified. No one cares if their project is optimized by default when they start working on it, but they do care the first time they go to build and it missing debug symbols.
https://mezzanine.blacktoppstudios.com/annotated.html
This is more of a convenience than a fix, but the Mezzanine list should be already expanded for the user when the page loads, as that will be the action taken on that page 99% of the time.
Using something like this:
set(CMAKE_CXX_CLANG_TIDY "clang-tidy;-style=file;-checks=*")
We can have clang tidy run with every target this could catch a few extra issues.
It is not critical to the test that the results actually work, but it doesn't hurt anything and would leave a good impression on people using it and serve as a better example.
Currently there is some modest support for cross-compilation like to IOS devices. But large swaths of the Jagati presume local builds. There needs to be some re-working of this to insure that local settings are used during cross-compilation and some way to determine if a build is cross-compiled.
A manual, preferably one well integrated into our other docs, needs to be created. This manual needs to cover a series of basic tasks and tickets for those should be made. This manual should be along the same level of sophistication and detail as The DAG Frame Scheduler Manual.
Some of those tasks this describe and details this might include should be:
Check these off once other tickets are made. Close this ticket once all are complete. This list should be updated as needed.
This is a warning about where vtables wind up. Largely this doesn't matter because modern linkers are smart enough to deduplicate extra vtables and the Mezzanine's source based distribution model guarantees recompilation and that the vtable will not be stale.
This warning provides no benefit and should be suppressed in the Jagati.
Right now the names that the Packages must provide for the source lists is implicit, it should be easier to work with and more implicit.
Perhaps they should be replaced with macros or something, but in the long run the current state is not maintainable.
There are several non-building custom targets in each of the Jagati Packages. These are all extremely similar and ought to be included in the Jagati to minimize code duplicate in our packages. These macros should make targets that make every passed file, or list of files, visible in IDEs like QtCreator or Code::Blocks.
When using the CMake GUI and trying to set MEZZ_PackageDirectory without having the environment variable set no setting you enter will be honored, and it will revert back to "[package-build-dir]/JagatiPackages" after the next configure.
This should either honor the setting provided by the user, or simply not exist as an option.
This was initially observed on MacOSX.
Jenkins should be hooked into every PR just like it is for our other repos.
Here are the flags defined by Jason Turner, a C++ trainer: https://github.com/lefticus/cppbestpractices/blob/master/02-Use_the_Tools_Available.md#compilers
What flags would help reduce possible issues?
https://mezzanine.blacktoppstudios.com/annotated.html
On that page Ogre is listed and can be expanded. This should be removed.
Not every wants to builds their workflow around CMake. Add install targets, that install build libraries, headers and testers so that a simple "make install" or "ninja install" will make all of the Mezzanine available in a more SDK like style.
Add support for the BTS Jenkins Cluster, Appveyor and Travis.
We have convenient checks for:
MEZZ_Linux, MEZZ_Windows, MEZZ_MacOSX
MEZZ_CompilerIsGCC, MEZZ_CompilerIsClang, MEZZ_CompilerIsIntel, MEZZ_CompilerIsMsvc
MEZZ_CompilerDesignNix, MEZZ_CompilerDesignMS, MEZZ_Arch64, MEZZ_Arch32
But there is no MEZZ_Debug
Whatever shape iOS support in issue #31 takes, this should probably look similar.
The first time CMake is run on any repo other that Mezz_StaticFoundation code coverage is always detected as off. The coverage is detected correctly in any following runs.
The current workaround in CI is to run CMake twice in Travis to get this detection to work correctly.
A game dev shouldn't be forced to catch both std::exception and Mezzanine::Exception::OutOfRange. We want to retain the benefits of having simple exceptions and a build system list of exceptions.
This should be easy to implement by changing AddJagatiException to accept a single item or a list. If it is passed a list then some simple manipulation should be able to split the list then write correct parameter lists and inheritance line.
Currently a there are a bunch of directories that just have their positions presumed, relative to the input directory, in project variables. These directory vars include:
If these are set in the project's CMakeLists.txt before calling CreateLocationVars() then that function should store the new value in the cache and the rest of the jagati should respect the change.
This is easy to implement but low priority because the opinionated nature of the Jagati creates a sane directory layout for the majority of projects and all jagati packages. The place where this might be implemented is in CreateLocationVars marked with a TODO.
Currently the Jagati can emit fairly sophisticated autogenerated test executables, but it doesn't support callingthose via "make test" or "ninja test". This should be an easy change, but is distinct from anything else we have been doing.
To play more nicely with ccache and prevent rebuilds in general the build directory for release builds should be "-release". This must cause a bunch of other changes, but it is likely to yield much greater productivity.
Here are the options that all should be brought into a single macro/function in the Jagati:
and Mako's
This might have a place in the StandardJagatiSetup to make cross-compiling and getting at advanced features as easy as possible. This will make this software more opinionated and should include a way to disable it.
CMake and CTest can have scripts with different compiler details. This would be simple for something like the jagati, it would just need to invoke RootTest.rb but could serve as the basis of test/Jenkins integration for other packages.
Currently a there are a 3 output files that just have their names presumed
${${PROJECT_NAME}BinTarget}
${${PROJECT_NAME}LibTarget}
${${PROJECT_NAME}TestTarget}
If these are set in the project's CMakeLists.txt before calling CreateLocationVars() then that function should store the new value in the cache and the rest of the jagati should respect the change.
This should be easy to implement but low priority because the opinionated nature of the Jagati creates a sane output names based on the PROJECT_NAME. The place where this might be implemented is in DecideOutputNames marked with a TODO.
Whatever we do in the Foundation for a timeout we should do to this one: BlackToppStudios/Mezz_Foundation#31
On msvc /permissive-
disables non-standard permissive behaviours. This could help avoid corner cases where the build breaks. This is default in newer version and the docs can be found here: https://docs.microsoft.com/en-us/cpp/build/reference/permissive-standards-conformance?view=vs-2019
This should be tested in the Jagati and if it doesn't break other packages it should be used by default. If it breaks everything horribly it should be documented here and dropped. If it needs some work it should be discussed.
The bare minimum has been done to support emscripten. This needs to be fully handled in every build configuration that emscripten might be used in (even on windows). Look at the emscripten toolchain definition: https://github.com/kripken/emscripten/blob/master/cmake/Modules/Platform/Emscripten.cmake
There should easy to use CMake variables to get information on the CPU familar and features. Currently the Jagati supports CPU architecture detection. Detection of specific families and features should allow decisions to be made in build system code about functionality like the existence of NEON, AVX256/512, SSE 1/2/3/4 and allow easier access to alignment information for vectorization.
This information should be made available to Mezz_StaticFoundation
Openmp simd should be researched to see if it have and
When doing a build on a machine without Git the Jagati attempts to execute commands that use git to download dependencies. This should be caught and detected and an error raised right here.
Instead the Jagati moves onto the next step and doesn't fail until it attempts to build something it didn't download and files or folders are missing.
There needs to be some way to specify code coverage flags on builds that support it. This should be easily combined with https://codecov.io/ and other similar services and tools.
https://mezzanine.blacktoppstudios.com/classMezzanine_1_1AreaEffect.html
Link provided for context. In the detailed descriptions for members in that link, the text is all the same colour with little to nothing to parse the separation from one member to the next. In the area with the brief descriptions Doxygen generates a line that can be seen to divide one member from the next, but the detailed area doesn't do this.
Aside from a line, changing the colour of the text for the member name is also a possibility (and these two aren't mutually exclusive) to help improve parsing/readability.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.