-
Notifications
You must be signed in to change notification settings - Fork 235
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
Project Restructure #31
Comments
Looks good, would it be overkill to nest all the code related folders in one master source folder? |
I dunno. I'm ambivalent as to whether the headers are separated into their own include dir. However I think that the separation of For example qhull is like an entirely separate project with its own project structure. I considered listing docsys there too. Fsengine and NvTriStrip are borderline. As of now FSEngine relies on the project for Qt, etc. But it's reasonably detached from the rest of the project's code. And in the future we might refactor FSEngine entirely since it can no longer work as-is under Qt 5.2. Basically anything we separate into its own config (e.g. CONFIG += fsengine) scope in NifSkope.pro should probably be placed under libs. I don't think src/src and src/libs really makes as much sense. |
Sorry should clarify, its not necessarily a source folder, just a general parent folder. |
I dunno. I think I wouldn't know what to call it as the libs aren't our source. If |
Makes sense. I think it just because I am looking at the current layout and its so cluttered, the proposed structure is perfect, just nitpicking :P |
Is there source for NifMopp.dll though? Best I can find is this: https://github.com/Ethatron/nifopt/blob/master/nifopt-hvk.C The DLL didn't come out of nowhere, and it's not directly from a vendor. I would prefer we have the ability to rebuild such dependencies if we needed to. Especially if we move on to newer compilers. I can't tell you offhand if the DLL would cause issues, but it's probable. Otherwise we would possibly have to force someone to use an old version if they want to update any MOPP code. |
Correction, separate project we created. https://github.com/niftools/mopper. |
Nah that's not quite it. It's going to be a file with these functions:
And that Both Mopper and that seem to be for standalone executables though. The Edit: Just noticed the license in the header of that
So it must be from somewhere... It just looks to be adapted around Nifopt in Ethatron's case. |
Yeah I think Mopper is the version used by pyffi for it Mopp code generation. I would suggest trying to contact either of the two above and see what they know. I know Skyfox had to use a newer version of the Havok SDK for the bhkCompressedMesh generation, but had decoded things to the point the he could write an open source version. He is currently however occupied with work given his post on the forum, but may still respond with general information. |
Issues (Updated)
|
Re point no. 8 |
I don't like that hardcoded stuff at all actually. I already took out some code that changes the directory to search for the shaders folder if the EXE is in a folder named "release" or "debug". hexabits/nifskope@d5875fa3 All that is for is just searching for nif.xml when the application starts. I'm not sure NifSkope should look for the docsys folder at all. It's relevant only to dev builds. I also copy nif.xml to the build folder along with kfm.xml, the lang and shaders folders, and the necessary DLLs (if a non-static build). Actually that code is only useful if you build NifSkope underneath the project directory, which qmake doesn't like (that's why they're called shadow builds). And even if you wanted to, the qmake script would place the nif.xml alongside the exe. I could technically leave the |
[WIP]
I put some comments in brackets. To elaborate:
resources
should possibly be moved to their own subdirres\icons
lib
a public interface.build
? Depends on if the .PRO should go inbuild
or the root.Changes will need to be reflected in:
Tracking
Refactor Progress #32
The text was updated successfully, but these errors were encountered: