-
Notifications
You must be signed in to change notification settings - Fork 22
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
Namespaces #551
Namespaces #551
Conversation
7b672a8
to
79df23f
Compare
With namespaces, the generated The fix so far is to re-order the swig I expect this will eventually lead to a circular dependency hell kind of situation... Currently the following are being generated without the appropriate namespace(s). They are sorted alphabetically so the order of these is not useful. // In flamegpuPYTHON_wrap.cxx ~ 3100 lines in but may move around.
#define SWIGTYPE_p_Agent swig_types[0]
#define SWIGTYPE_p_AgentDataBuffer swig_types[1]
#define SWIGTYPE_p_AgentDataBufferStateMap swig_types[2]
#define SWIGTYPE_p_AgentDataMap swig_types[3]
#define SWIGTYPE_p_AgentInterface swig_types[4]
#define SWIGTYPE_p_AgentOffsetMap swig_types[5]
#define SWIGTYPE_p_CAgent swig_types[6]
#define SWIGTYPE_p_EnvironmentDescription swig_types[7]
#define SWIGTYPE_p_FGPURuntimeException swig_types[8]
#define SWIGTYPE_p_FLAMEGPU_HOST_FUNCTION_POINTER swig_types[9]
#define SWIGTYPE_p_HostAPI swig_types[10]
#define SWIGTYPE_p_ModelDescription swig_types[11]
#define SWIGTYPE_p_MsgBruteForce__Description swig_types[12]
#define SWIGTYPE_p_NameStatePair swig_types[13]
#define SWIGTYPE_p_RandomManager swig_types[14] |
Right now, a single pytest is failing in Building with vis enabled is currently generating some wonky types. Looks like either the vis swigging needs to occur earlier, or if vis is enabled some additional forward declarations might be required (possibly just the one of ModelVis, which is available via CUDASimulation?) After that, python should work and actual work on additional namespacing / renaming things / sorting header file types / moving files around can resume. |
Oddly all tests are currently passing for VIS=OFF builds, unsure why the brute force test failiure is no longer occuring.. |
ddf3cd0
to
bd59a48
Compare
7a5f81b
to
93fd9e2
Compare
Updates all tests and examples to use these new namespaces Complete rewrite of pyflamegpu.i to generate a single python module that uses the appropraite classes. Adds some missing override statments Adds new tests to check namespaces can be used in several ways Improves some exception/error strings Removes an unneccesary header dependency by moving a typedef.
This requires workarounds for CMake < 3.20, where genex cannot be used as byproducts Instead, single-config generators use CMAKE_BUILD_TYPE. multi-gen's do not specify byproducts, as the output path being consistent is more important Unclear if byproducts actually have impact in vs/multi-generator configs in general Fix byproducts with mulitgenerators and older cmake
CMake exclusively only allows a single platform to be specified for a given build directory, regardless of single or multi config generator
Potentially this could become flamegpu.cuh given it includes other headers which should be .cuh, But in practice, we want users to just include .h when we eventually have a non-cuda build, and isntead the header should have #ifndef CUDACC to include the .cuh headers if being built with cuda support?
Not always included by .cu files still.
…_dependency_graph example This is currently causing segfaults, which will be addressed in a separated PR/commit
…, __shared__, etc)
This provides a suprising improvment to RTC build time
Once CI passes this should be in a mergable state. History is made up of meaningful isolated commits so i'd prefer a rebase / ff merge than a squash. I've opened new issues to track the other outstanding changes which didn't make it in. I've not changed the pop/sim/runtime/gpu directories in the end, unhappy with the alternatives but it shouldn't be a big deal to move these files around in the future (renameing / namespacing might be, but that is going to be a breaking change if / when it happens anyway) |
Introduce C++ namespaces to the library, to avoid polluting the global namespace.
This is not as namespacey as I would like, however due to time / complexity it will do for now.
flamegpu
namespaceexception
- mostly just to clean up the docsio
- nicely self-contained.util
- quite self containeddetail
namespaces - parts of headers that users ideally shouldn't know existsFlatten the file hierarchy forgpu
,pop
,runtime
,sim
? - 70+ headers currently....cuh
.std::pair<X,Y>
mostly)namespace flamegpu {
,using namespace flamegpu
, orusing flamegpu::MsgNone
etc)os-platform
fromlib
/bin
directory paths. It was unneccesary.BUILD_SWIG_PYTHON_VIRTUALENV
->BUILD_SWIG_PYTHON_VENV
__threadsync()
toAgentFunctionWrapper
whenSEATBELTS
is on. Closes Missing threadsync in the agent function wrapper #568.Todo pre-merge:
Todo pre/post-merge:
Open issues:
MsgNone
does not matchmessaging/None.h
/messaging/None/NoneHost.h
. Couldn't move this tomessaging
namespace because of mutual friendship (probably fixable, with effort / time, might cause issues with swig too, unsure).Update each standalone repo to use the namespaces