Generated msvs solution files do not appear to work #322
Comments
|
I should say, I was able to get core.vcxproj to load by manually changing the <Project ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">I was also able to get core.vcxproj.filters to load by removing all references to the full path in the |
|
I think that visual studio option was added almost 10 years ago but was never really used by anyone. If I recall correctly, the main reason was that whatever studio files it generates are just a wrapper around the scons build process, so it wasn't all that useful. It sounds like it's not even doing that properly any more, so I suspect we'll just remove the option. (By the way, the scons that is packaged with Soar is an older version, so it's possible that it's no longer generating files compatible with the current version of Studio.) |
|
I actually disagree that its not useful. It's super useful for debugging on windows (which is what I'm doing now). I actually know that another project actually made their own VS solution for csoar, because the generated one doesn't work. Maybe it's as easy as updating to a more recent scons version. Or perhaps it would be better to move to cmake, as that seems much more popular these days. But of course I understand if the resources to address this just aren't available. |
|
@garfieldnate fixed the project file generation so it includes the proper paths instead of what appears to be python object strings. The solution file and projects now load without issue. However, when I try to build, I get these errors: |
|
Looks to me like SCons is assuming that it's been pip-installed instead of there being a copy in the build directory, which is our setup. |
|
@marinier Could you upload the generated files? It would help with debugging SCons. |
|
@marinier As a workaround, could you try pip-installing SCons? We don't have any custom patches applied to the one in the repo. Actually, I'm not sure why we use a local copy of it at all. mwichmann says it seems like SCons has no concept of a local install when generating the MSVS files: https://discord.com/channels/571796279483564041/1059858077597302825/1059861690797281340 |
|
The other thing to try would be to set the |
|
Here are the project/solution files. |
|
Setting pip installing SCons DOES work, though. Building the project appears to mostly work, but there are some errors. Here's the output for a non-parallel build after the build has already failed (so this only includes the failure parts): |
|
And you did run that from inside Visual Studio, right? Because the IDE is supposed to define the |
Not environment var - this is an SCons construction variable. Like this: diff --git a/SConstruct b/SConstruct
index dff447dfb..fea41bf87 100644
--- a/SConstruct
+++ b/SConstruct
@@ -170,6 +170,7 @@ env = Environment(
SML_TCL_ALIAS = SML_TCL_ALIAS,
# indentation for log formatting
INDENT = ' ',
+ SCONS_HOME=os.path.join(os.getcwd(), 'scons', 'scons-local-4.4.0')
)
env.AddMethod(prepare_for_compiling_with_tcl, 'PrepareForCompilingWithTcl')This works for my experiment on this (still using the scons-local distribution). However, I get the same failure trying to build, a |
We are building with Visual Studio 2022, and Microsoft has refactored/ reorganized/renamed the redistributable C++ runtime libs. See the docs: https://learn.microsoft.com/en-us/cpp/windows/determining-which-dlls-to-redistribute Our last release didn't include the DLL's simply because they weren't in the location we expected to copy them from anymore. But the DLL's are now only required when distributing for Windows before version 10; 10 and later come with the runtime libs pre-installed. So: our last release would have broken Soar for any users that didn't have the runtime installed on a distribution of Windows 8 or older. No one has complained yet... though that isn't a guarantee. To support them, we would have to re-write this logic to include the correct DLL's. Since this code is currently broken, and is in the way of resolving issue #322, I'll delete it for now. We can come back and write correct DLL-inclusion code later if needed.
|
@marinier I removed the bit that looks for VCINSTALLDIR from the project, and pushed mwichman's suggested edit, as well. Could you pull development and try again? You shouldn't need SCons pip-installed anymore. |
This is necessary for SCons to generate the MSVS project files. See #322 (comment).
|
Everything builds now, even with SCons not pip installed! I was able to run the CLI from VisualStudio, but I haven't figured out how to actually debug (it says no symbols are loaded). This may be because there is only a release configuration generated, not a debug one? |
|
Could you try adding |
|
Adding FWIW, ideally the generated solution+project files would always have both a debug and a release configuration. |
|
Great to know that it worked! I can't take this any farther right now, so I'll leave the issue open. |
|
I do remember that the JSoar compatibility work replaced /Z7 with /Zi in the debug build. It might be worth trying changing that back. /Zi and /Z7 both generate symbols, but in different formats. Documentation here: https://learn.microsoft.com/en-us/cpp/build/reference/z7-zi-zi-debug-information-format. /ZI looks interesting, too! |
|
And generating both Release and Debug variants of MSVS should be as simple as updating the |
|
In order to debug, Visual Studio needs to generate .pdb files as part of the build (these contain the symbols). I noticed that the pdb files I had were very old, so I deleted them and did a clean rebuild, and they were not regenerated. I followed the instructions here: https://stackoverflow.com/questions/23390936/how-to-generate-msvc-solution-with-debugging-information-using-scons That is, I modified Now a bunch of pdb files get generated, which is great. However, Visual Studio still can't seem to find the files at debug time. I read elsewhere that they have to be in the same directory as the .exe being run. The pdb files that get generated are in various subdirectories of the I also tried renaming the pdb file (it gets named So then I tried your suggestion of changing So I'm still confused as to what the problem is. |
|
BTW, another thing I noticed is that the build only succeeds if it is single threaded. My Visual Studio was configured to use up to 12 threads by default, and it tried to build all the projects (core, cli, unittests) in parallel and eventually gave errors about not being able to open certain files (probably because some other thread still had them open?). If I configure visual studio to use only 1 thread for building, then it works fine. The setting I was changing was a global setting (not part of the project settings). I don't know if there's a way to override the global setting at the project/solution level, or perhaps to set dependencies in some way such that the projects are forced to build sequentially. |
|
We'll talk about this some over on the SCons side. MSBuild's idea of building what it thinks are several projects in parallel isn't going to mesh with calling scons, which thinks it's one project. SCons itself can do parallel builds, but it can't support multiple instances building the same tree concurrently - in particular, the |
|
FWIW, if you want to configure the project on the SCons side to do parallel builds, you can add something like: SetOption('num_jobs', os.cpu_count())in your SConstruct file. That's not perfect - you don't have build-time control of how many jobs if MSBuild is firing off the build, but should help with build times. EDIT: sorry, I forgot to put the option name in quotes, updated. |
|
Moritz has a basic CMake-based build/install script for Soar here: https://github.com/moschmdt/Soar/blob/e6e5b88d634edac16489333a8371511470c08b84/CMakeLists.txt. It doesn't include SVS or the Java projects. He also shared some potential starter code for compiling with SCons or other external tools from CMake, which might enable a sort of intermediate step where we migrate the build piece-by-piece: cmake_minimum_required(VERSION 3.14)
project(MyProject)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
include(ExternalProject)
# Define the external project
ExternalProject_Add(
Soar
PREFIX ${CMAKE_BINARY_DIR}
GIT_REPOSITORY https://github.com/SoarGroup/Soar.git
GIT_TAG development # or a specific tag or branch
CONFIGURE_COMMAND "" # No configure step needed for SCons
BUILD_COMMAND python3 scons/scons.py --scu kernel scripts headers # Command to build the project with SCons
INSTALL_COMMAND "" # No install step needed
BUILD_IN_SOURCE 1 # Build in the source directory
)
# Specify the include directories and library paths
ExternalProject_Get_Property(Soar source_dir)
ExternalProject_Get_Property(Soar binary_dir)
message("Source dir of myExtProj = ${source_dir}")
# Assuming the built library is a static library named 'libmylibrary.a'
set(MY_LIBRARY_INCLUDE_DIRS ${source_dir}/out/include)
set(MY_LIBRARY_LIBRARIES ${source_dir}/out/libSoar.dylib)
message("DYLIB dir of myExtProj = ${MY_LIBRARY_LIBRARIES}")
# Add the include directories and link the library to your target
add_executable(MyExecutable main.cpp)
add_dependencies(MyExecutable Soar) # Ensure MyExecutable waits for the library to be built
target_include_directories(MyExecutable PRIVATE ${MY_LIBRARY_INCLUDE_DIRS})
target_link_libraries(MyExecutable PRIVATE ${MY_LIBRARY_LIBRARIES})
# Set rpath to the directory containing libSoar.dylib
set_target_properties(MyExecutable PROPERTIES
BUILD_RPATH ${source_dir}/out
INSTALL_RPATH ${source_dir}/out
) |
|
I did some testing with cmake again today and an issue where the Soar CLI interface was not included due to the generated Downstream projects should be able to fetch and build the Soar library with the following cmake snippet: include(FetchContent)
FetchContent_Declare(
Soar
GIT_REPOSITORY https://github.com/moschmdt/Soar.git
GIT_TAG development
)
FetchContent_MakeAvailable(Soar)
# Then link the library to the executable
add_executable(main main.cpp)
target_link_libraries(main Soar)Nonetheless, for using the debugger etc. the installation of the Soar release is still necessary. |
|
@JBoggsy I know you build Soar regularly. We are preparing to move to CMake instead of SCons. Do you have any input/opinions on this? |
|
First take: Yes! Please! I only skimmed this thread, but this kind of silliness seems typical of my experience building Soar with SCons. Having built in VS before, it is, in fact, a huge pain. Also, I used to run into problems where SCons required a different version of Python than Python libraries I wanted to use via SML. The update to the SCons version has fixed this, but the possibility it could happen again exists. Also, many libraries include CMake examples in their tutorials; I've yet to find one which has a SCons example. That being said, please don't replace SCons until SML and SVS are both compilable. |
|
Great, thanks for your input! We will not put Soar into a state where it has no complete automated build, even temporarily. It will probably have partial CMake support for a while, and then only when the CMake support is complete will we remove SCons. |
Using
build msvsappears to generate project files that don't work. At least, they don't appear to be migratable to newer versions of Visual Studio.First, it's not clear what version of Visual Studio these generated files are intended to work with, but if I try opening in VS 2015 or 2017, it wants to upgrade them. The upgrade fails for most projects (the solution itself upgrades fine). (Do we really still need to support versions older than 2015?)
Second, the contents of some of the files appear to be mangled. E.g., unittests.vcproj contains this block, which is not valid XML:
It looks like there may be a bug in the scons that doesn't output the actual file names, but instead gets these internal object references.
It also fails to upgrade all of the *.vcxproj.filters files. I'm not sure why (it's valid XML).
The text was updated successfully, but these errors were encountered: