blacktoppstudios / jagati Goto Github PK

Add support for the BTS Jenkins Cluster, Appveyor and Travis.

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.

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.

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

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.

We don't know exactly what this will look like but we need to expand the jagati to allow easy building of iOS apps.

Clang on apply was incorrectly detected as not supporting --coverage, which is what we use for coverage.

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.

Whatever we do in the Foundation for a timeout we should do to this one: BlackToppStudios/Mezz_Foundation#31

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.

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.

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.

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

https://mezzanine.blacktoppstudios.com/annotated.html

On that page Ogre is listed and can be expanded. This should be removed.

Jenkins should be hooked into every PR just like it is for our other repos.

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.

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).

Whatever shape iOS support in issue #31 takes, this should probably look similar.

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.

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:

1. ${${PROJECT_NAME}DoxDir}
2. ${${PROJECT_NAME}IncludeDir}
3. ${${PROJECT_NAME}LibDir}
4. ${${PROJECT_NAME}SourceDir}
5. ${${PROJECT_NAME}SwigDir}
6. ${${PROJECT_NAME}TestDir}

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.

Here are the options that all should be brought into a single macro/function in the Jagati:

• MEZZ_BuildDoxygen
• MEZZ_BuildStaticLibraries
• MEZZ_CodeCoverage

and Mako's

• Mezz_BuildIOS

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.

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.

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.

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

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.

Every functions should be looked at and a ticket made for it, this is to help manage the complexity

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.

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.

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.

• Works from more than one repo
• Better Bit pattern Research/Discussion/Result
• Consider automating bit pattern
• Allow arbitrary namespaces
• Remove Java Exception stuff
• Remove or download files

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.

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.

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.

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.

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

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.

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

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.

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.

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?

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 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.

Add tests to make it easier to refactor with confidence. This will help make it easier to split out the Documentation because

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.

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.

A call to CreateCoverageTarget always creates the target if it is supported by the compiler whether or not the game dev disabled this.

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:

• Start writing the docs somewhere (StaticFoundation?) and provide something the rest of these might be jammed into.
• Explain what the index and how to use a different index.
• Make all repos on a machine use the same source folder or different source and why that might be good.
• Control whether or not Jagati files are downloaded.
• Explain how the checksumming works and how it is a security feature.
• How to create build config files and explain the problems that solves.
• Say something about project structure and explain the opinions the Jagati enforces.
• List all jagati variables.
• Explain all the variables can be pre/overloaded.
• Describe OS, Compiler and CPU detection in detail, and describe the relation with Mezz_StaticFoundation.
• Describe file lists and provide a few examples.
• Show how to run the unit tests.
• Explain how to use the code coverage feature to let people know how to figure out their test coverage.
• Explain the opinion about each Jagati Package having one lib, one exe, and one tester.
• Describe Doxygen integration.
• Explain the presumptions the Jagati makes during linking.
• Describe how to add 3rd party libraries manually.
• Describe automated test executable generation with Mezz_Test.
• Explain the IDE Visibility feature.
• Explain how this uses/abuses git.

Check these off once other tickets are made. Close this ticket once all are complete. This list should be updated as needed.