# Windows build scripts and simplification
**URL:** https://discourse.slicer.org/t/windows-build-scripts-and-simplification/1431
**Category:** Development
**Created:** [November 10, 2017, 12:45pm UTC](https://discourse.slicer.org/t/windows-build-scripts-and-simplification/1431 "2017-11-10T12:45:02Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@ihnorton](https://discourse.slicer.org/u/ihnorton)
#### Post date: [November 10, 2017, 12:45pm UTC](https://discourse.slicer.org/t/windows-build-scripts-and-simplification/1431/1 "2017-11-10T12:45:02Z")
> [@Build Error PythonQt Visual Studio 2015 Qt 5.9.2](https://discourse.slicer.org/t/build-error-pythonqt-visual-studio-2015-qt-5-9-2/1411/15):
>
> For some time I have been thinking about creating a “SlicerDevelopmentEnvironment” project on GitHub where we would keep:
>
> This would ne lightweight and allow to store:
>
> batch/shell script to build Slicer
> and other misc scripts
>
> Or we could commit batch script directly to Slicer repo.
>
> Here is what was done for ITK: [GitHub - InsightSoftwareConsortium/ITKDevelopmentEnvironment: A repository of scripts to set up an ITK development environment.](https://github.com/InsightSoftwareConsortium/ITKDevelopmentEnvironment)
In-repo sounds fine for a `quickbuild.bat` type of script, but remember that this will add another layer of indirection and potential confusion (“I tried the quickbuild.bat but it kept rebuilding everything from scratch and failing after 3 hours! Then I tried the superbuild instructions directly”, etc.).
I think providing a link (or automatic download) of correct Qt binaries would go further to simplify the development process on Windows. The current 5.9.2 official binaries ship both release and debug DLLs + PDBs, however Creator and Designer appear to only be built in release ☹.
Probably best to keep Docker scripts outside of the repository as they are now.
---
### Author:  [@lassoan](https://discourse.slicer.org/u/lassoan)
#### Post date: [November 10, 2017, 1:38pm UTC](https://discourse.slicer.org/t/windows-build-scripts-and-simplification/1431/2 "2017-11-10T13:38:46Z")
I agree that it would be better not to add one more automation layer on top of CMake for building Slicer on a developer computer (fully automated Docker builds is a different story). To make the build process more robust, I would prefer to improve CMake scripts and/or documentation.
---
### Author:  [@jcfr](https://discourse.slicer.org/u/jcfr)
#### Post date: [November 10, 2017, 2:27pm UTC](https://discourse.slicer.org/t/windows-build-scripts-and-simplification/1431/3 "2017-11-10T14:27:37Z")
> I would prefer to improve CMake scripts and/or documentation.
👍
Regarding CMake improvement, it is a matter of finding:
- time to move the patch forward and implement tests
- the right trade-off between feature creep
That said, I have been quite successful in adding and improving features (e.g improved support for cross compilation initiated by @thewtex, …)
---
### Author:  [@thewtex](https://discourse.slicer.org/u/thewtex)
#### Post date: [November 10, 2017, 3:01pm UTC](https://discourse.slicer.org/t/windows-build-scripts-and-simplification/1431/4 "2017-11-10T15:01:04Z")
For ITK GitHub CI builds, we are investigating Docker Windows images in addition to Docker Linux images. It looks compelling.