NifSkope.pro file cleanup about nifskope HOT 11 CLOSED

Latest Revisions

NifSkope.pro
NifSkope_functions.pri
NifSkope_targets.pri

Commits

Initial .pro/.pri config modifications hexabits/nifskope@017af40
Minor .pro/.pri cleanup hexabits/nifskope@a0c1b56
Better sed support for Windows hexabits/nifskope@dc31ac2
More robust multi-platform file copying hexabits/nifskope@20ba5fe

from nifskope.

While working on qt5/restructure, I am cleaning up the NifSkope.pro file.

Here is my current progress: https://gist.github.com/jonwd7/9348265

I currently:

1. Clean up the build dir significantly using UI_DIR, MOC_DIR, OBJ_DIR, RCC_DIR to put them in appropriate subdirs.
2. Copy the appropriate Qt DLLs, the shaders and lang folders, and the XMLs to the build dir. DLLs only when the build is not static.
3. Cleaned up the compiler scopes slightly.

I still need to:

1. Flesh out the compiler scopes. Being explicit with compiler flags is best.
2. Possibly do build subdirs for x86/amd64, and/or build to a subdir for each Git revision. Meaning, you can make a commit, build it, and it will not overwrite builds from previous commits. A way of keeping a build history for comparison.
3. If I can successfully target VS2010/2012 and differentiate it from Qt Creator, the macro fix above may not be necessary.

One thing I'm kind of annoyed with is how cleaning up the project directories has made the actual organization of the IDEs worse... That is, the Headers and Source trees are no longer flat, but say Headers > src and Source > src ... Which is redundant and also annoying to have to expand another level to get to the source files. It's a one-time issue though, as they are only collapse when you open the project.

from nifskope.

Do we need to update the nif.xml & kmf.xml sub-modules repositories.
git --submodule update will pull the latest but need to check if the docsys .gitmodules point to gihub or sf.net repos.

Edit: Checked there. They point to the old sf.net versions so that needs to be updated, or at the very least synch'd.

from nifskope.

[submodule "docsys"]
    path = docsys
    url = git://niftools.git.sourceforge.net/gitroot/niftools/nifdocsys
[submodule "qhull"]
    path = lib/qhull
    url = git://gitorious.org/qhull/qhull.git

The lib/qhull is because I moved qhull. It's just qhull in the official branch.

from nifskope.

Yeah I checked the .gitmodules in the sf.net docsys and they point to the sf.net versions. They are out of date. Qhull is fine as its external.

from nifskope.

OK, I've split off some things into a PRI file (project include). Here is the current setup:

NifSkope.pro
NifSkope_functions.pri

I did this to de-clutter the main .pro file. I could even split a few other things into PRI files. I may also move the version/revision macros to the PRI file.

from nifskope.

I've updated the files:

NifSkope.pro
NifSkope_functions.pri

In QMAKE_PRE_LINK I use sed to grab build\README.md.in, and replace the @VERSION@ string with the version stored in build\VERSION. I then output it to .\README.md. For Windows, it looks for GnuWin32's sed. It doesn't do anything if it's not there. I would like to query for the sed command and see if it exists on the path, but I'm not positive there is a foolproof way to do this. The system() function which is supposed to help with this seems unreliable. For linux it just assumes sed is a valid command on the path.

In QMAKE_POST_LINK I then copy all the .md (Markdown text, from the repo) files from the project root and rename them to .txt and put them in the build directory.

I also now copy the style.qss file and qhull/COPYING.txt to the build dir.

Basically the build directory now looks exactly like the official release, with the exception of the docs folder.

Regarding that, I have some targets to make. In the .pro file you can define extra targets which you can then run make commands for them. So I can create a docs target which runs nifxml_doc.py and installs the docs to the build directory. It'd be simply make docs or make -f Makefile.Release docs depending on if I can get rid of the separate debug/release targets which happen because we use the options debug_and_release and debug_and_release_target. I may be able to work around it, but I'm not sure yet.

Also, not relevant to the release package / installer, I can make a doxygen target which builds the NifSkope API docs. What I found out about Doxygen is that it can also build a QCH (Qt Compressed Help) file so that the NifSkope docs can be loaded directly inside of Qt Creator. Updating the QCH file requires Qt Creator to be closed I believe, or it won't update. I'm not 100% certain on that, and it may just not show the updated files until a restart, but the file does get written correctly.

So, I can make a Doxygen target for both the normal online docs and the docs for Qt Creator.

I guess an alias of jom -f Makefile.Release docs is just jom release-docs. So that's more than simple enough.

from nifskope.

OK, docsys target was pretty easy I must say. Here is the current state of the targets PRI file:

NifSkope_targets.pri

I generate the HTML files, move them to the build dir, copy the CSS/ICO file, and then clean up the .pyc file so that the submodule doesn't get marked dirty.

from nifskope.

would it make it easier just to add .pyc to the .gitignore?

from nifskope.

I thought that, but it doesn't work. You're still adding a file to a submodule and git considers that dirty. It could work if it's added to the docsys .gitignore. Maybe.

from nifskope.

The latest versions can now be seen from here:

NifSkope.pro
NifSkope_functions.pri
NifSkope_targets.pri

The commits:

Initial .pro/.pri config modifications hexabits/nifskope@017af40
Minor .pro/.pri cleanup hexabits/nifskope@a0c1b56
Better sed support for Windows hexabits/nifskope@dc31ac2
More robust multi-platform file copying hexabits/nifskope@20ba5fe

from nifskope.