Skip to content
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

Clean rebuild from source - CMake? #2

Open
bscottm opened this issue Jul 20, 2019 · 3 comments
Open

Clean rebuild from source - CMake? #2

bscottm opened this issue Jul 20, 2019 · 3 comments

Comments

@bscottm
Copy link

bscottm commented Jul 20, 2019

I rebuilt windows-build from scratch and the whole build process is a bit of a mess. I was wondering how receptive all you all might be to accepting a future pull request that uses CMake to build the libraries and put them into a reasonable directory structure, with updated version of the libraries (libpng, for example, is significantly behind.)

@markpizz
Copy link
Member

User rebuild of this stuff is absolutely not the intention. It is a static collection of things which have been carefully built to work and are customized to the various versions of Visual Studio that are supported. Changes to this repo are few and far between (once or twice a year or when a new version of Visual Studio is released - I'm working on VS2019 which will be added soon).

I'll be adding that explicit detail to the README.md

I looked at updating the libpng version, but it was much more trouble than it was worth. There is currently only one use of libpng (the SCREENSHOT command for simulators that have graphics devices).

If you want to design a different build paradigm for simh (including potentially a different paradigm for dependencies), feel free to do that and come back with something that works for all versions of visual studio, MinGW and the other supported host OS platforms and we'll check it out when you're ready. No problem asking questions along the way. From my point of view I think you are looking at a significant hill to climb with little potential gain.

The careful build of this stuff aligns with the strategy that on non windows platforms, we explicitly do not support user built dependent libraries, but only count on OS supplied (or standard package distribution facilities) which presumes that those who put together the OS supplied packages have tested them and they work solidly on the particular host platform. This strategy was implemented as a consequence of early days experiences, where we had significant problems chasing down problems due to user built packages that weren't otherwise known to work.

markpizz added a commit that referenced this issue Jul 20, 2019
@bscottm
Copy link
Author

bscottm commented Jul 21, 2019

CMake is a meta-build system, very cross platform and multi-compiler. For example, it'll generate solutions for VS2015, VS2017 and VS2019, x64 and x86, as well as for MingGW mingw32-make. It'll give you some control over where libraries, DLLs and headers are installed, so that you won't have that ugly lib\Release hack and copy files. If you look in some of the source directories, you'll find CMakeLists.txt files, which are CMake build prototypes, so using CMake isn't much of a stretch.

There exists a pthreads42-cmake, which is pthreads4w with a CMakeLists.txt build prototype.

The interesting challenge will be winpcap, which is obsolete. It looks like that's only the SDK, which doesn't look like it needs to be built from source.

From what I can see, it looks like the only change I'd have to make to the sim-master side is pointing the WinXX-specific include and library variables to a different directory, maybe copy DLLs over to the BIN directory.

Minor point for discussion: Keeping up with software versions. Let's say there's old PDP-11 software that used to run in a control room on a Boomer. Government cyber types walk in, point out that there are five CVEs in libpng, failing simh in the Risk Management Framework and simh can't be run on a machine connected to a network (which is a major inconvenience in today's world.)

My point: There are use cases for simh where the user has to be mindful of people with checklists.

@bscottm
Copy link
Author

bscottm commented Aug 18, 2019

@markpizz: I have a working proof-of-concept in bscottm/windows-build and bscottm/simh on the windows-build and cmake branches, respectively. Prerequisites are cmake 3.15 and 7z in addition to your development environment. I use scoop.sh to install localized tools like cmake and 7z.

git clone https://github.com/bscottm/windows-build.git
cd windows-build
.\cmake-builder.ps1 -tool:vs2019

All build artifacts (libraries, DLLs, headers) reside in the build-stage subdirectory. We can quibble about configuration- and architecture-specific subdirectories, but for the time being, everything goes in one staging directory.

Caveat: I assume that you have Npcap installed. I'm on Windows 10, so for me, it's Npcap for networking.

cd ..
git clone https://github.com/bscottm/simh.git sim-master
cd sim-master
git co cmake
mkdir cmake-build
cd cmake-build
cmake -G "Visual Studio 16 2019" -Awin32 ..
cmake --build . --config Release --target install
ctest -C Release -V

I'm working on a Powershell script to automate the sim-master build.

NOTE 1: Open the simh.sln solution in the cmake-build subdirectory in Visual Studio. If you prefer VS 2017, use "Visual Studio 15 2017" instead of the 2019 generator.

NOTE 2: This isn't intended to completely replace the existing simh build system. But it does reduce the VS solution maintenance (2017, 2015 are supported generators, as are MinGW makefiles and Ninja.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants