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.

Sign up for GitHub

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

Jump to bottom

Problem building from cmd line W10 Visual Studio 2019 - CMake 3.16 - problem found #284

Open
marcoxa opened this issue Apr 17, 2020 · 8 comments
Open

Problem building from cmd line W10 Visual Studio 2019 - CMake 3.16 - problem found #284

marcoxa opened this issue Apr 17, 2020 · 8 comments

Comments

@marcoxa
Copy link

marcoxa commented Apr 17, 2020

Hi

I figured out why the build on W10 does not work.

It looks like a CMake buglet dealing with "in source" building.

The issue is that

CMAKE_DISABLE_IN_SOURCE_BUILD and
CMAKE_DISABLE_SOURCE_CHANGES

appear to be "undocumented" in CMake, hence possibly quite frail.

I commented out the following in CMakeLists.txt

# set( CMAKE_DISABLE_IN_SOURCE_BUILD ON ) 
# set( CMAKE_DISABLE_SOURCE_CHANGES  ON )

and now

c:/my build folder that is not the source> cmake c:/the/hyperion/source

works like a charm.... until

-- ---------------------------------------------------------------------------------
-- Retrieving SoftFloat-3a, S3FH, from "https://github.com/hercules-390/SoftFloat-3a", branch master
...
...
@@ Building SoftFloat revision 1-[1f24457298fb]+
@@ Local  build
@@ Available configuration Types: Debug;Release
CMake Error at C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.16/Modules/CheckIncludeFile.cmake:55 (configure_file):
  configure_file attempted to configure a file: C:/my build folder that is not the source/extpkg/SoftFloat-3a/build/CMakeFiles/CMakeTmp/CheckIncludeFile.c
  into a source directory.
Call Stack (most recent call first):
  cmake/modules/CheckHeader.cmake:26 (check_include_file)
  CMakeLists.txt:180 (check_header)

-- Configuring incomplete, errors occurred!

Looking into CMakeLists.txt of SoftFloat-3a we find again the

set( CMAKE_DISABLE_IN_SOURCE_BUILD ON ) 
set( CMAKE_DISABLE_SOURCE_CHANGES  ON )

Comment them and the generation works.

Don't ask me why, but it does.

I suggest this simple fix is made to the two CMakeLists.txt files.

All the best

Marco Antoniotti
@ghost
Copy link

ghost commented May 24, 2020

C:/my build folder that is not the source
is that the real name of the build directory ?

in the docs it is stated that directories/path with spaces are not supported
I was curious and the build fails even if with different errors on Apple High Sierra/Mojave

anyway

set( CMAKE_DISABLE_IN_SOURCE_BUILD ON )
set( CMAKE_DISABLE_SOURCE_CHANGES  ON )

even if not well documented are perfectly legal ...
and they prevent cmake from writing to the source directory

I suggest this simple fix is made to the two CMakeLists.txt files.
it might work in Your environment but there is no proof that they are the cause of Your errors

the same statements on
apple OSx from El Capitan
linux fedora from 27
Centos from 7
Ubuntu from 14
debian from 8
FreeBSD from 11
all work asis

OpenBSD 6, NetBSD 8, DragonFlyBSD, fail for other reasons but NOT because of the quoted statements

right now this version of Hercules seems not maintained any longer
You can find a a more actively maintained version here

https://github.com/SDL-Hercules-390/hyperion

it contains the same exact statements , and they do NOT cause any errors
( the working platform for the main maintainer/developer is ... WINDOWS )
so He should know

my best regards
E

@marcoxa
Copy link
Author

marcoxa commented May 26, 2020

Thank Enrico

After some further investigation I believe that maybe I was just wrong in using CMake (a program that I find rather ... confusing). I believe the issue is "where" you start CMake from. I was starting "inside" the build directory, hence the I was triggering the issue I reported.

Unfortunately, the undocumented features sent me off the wrong track.

In any case, I did not explore further these issues as I downloaded the SDL version, as you suggested; it seems to work well, although that one also has some build issues, as it insists on doing things that the latest Microsoft toolchain release does not quite like.

All the best

Marco

@Fish-Git
Copy link
Contributor

Fish-Git commented May 27, 2020 •
edited
Loading

In any case, I did not explore further these issues as I downloaded the SDL version, as you suggested; it seems to work well, although that one also has some build issues, as it insists on doing things that the latest Microsoft toolchain release does not quite like.

Marco (@marcoxa),

Can you tell me what "build issues" you are experiencing?

Can you tell me what "things" SDL Hyperion is insisting on doing that "the latest Microsoft toolchain release does not quite like"?

Thanks.

@marcoxa
Copy link
Author

marcoxa commented May 28, 2020 via email

@Peter-J-Jansen
Copy link
Contributor

Marco,

I think the Win32.mak file you found missing will be included if you also select a "Windows 10 SDK" component to install in VS 2019 CE, like on this screenshot of mine (from November 2019). That is if remember correctly ;-).

Cheers,

Peter

image

@Fish-Git
Copy link
Contributor

Marco,

Being new to Hercules, you probably failed to follow the documented build procedure for Hercules.

Every open source product has its own build procedure, explaining the proper way to build the product, and it's usually not as simple as just downloading the source and clicking build. There's usually some other preliminary steps you need to perform before actually attempting to build the product. Such is true with Hercules.

The SDL Hyperion 4.x version of Hercules is no different. It's documented build procedure for Windows (Visual Studio) is here:

PLEASE NOTICE that one of the required steps when installing Visual Studio is to also select the "Windows XP Support" installation option. This is the option that installs the Win32.mak file.

For Visual Studio 2019, that option is in the "Individual components" section and is called "C++ Windows XP Support for VS 2017 (v141) tools":

PLEASE ALSO NOTICE that there are other preliminary preparation steps which must also be completed beforehand before you can successfully build Hercules, the most important of which is Step 2 as described on the previously mentioned "Hercules Windows Build Instructions" web page:

  • 2. Define Environment Variables and Fix Property Sheets

Once you complete those two required steps, then you should be able to build Hercules with no problems.

As far as the Visual Studio .sln (Solution) file is concerned, using the VS2017 solution file instead should work just as well. We will eventually create a VS2019 solution file too, but we prefer to wait a while before doing so.

IF YOU HAVE ANY PROBLEMS, it would be best to create a new GitHub Issue on the SDL HYPERION Issues web page, AND NOT HERE!

Thanks.

@marcoxa
Copy link
Author

marcoxa commented May 28, 2020 via email

@Fish-Git
Copy link
Contributor

Having said that, the messages ended up here because I first tried this version of Hercules before finding the SDL one.

Understood. I didn't mean to yell. I guess I shouldn't have used all CAPS and just a simple period instead of an exclamation mark too. I just wanted to make clear that what we're dealing with now is an SDL Hyperion issue, so technically we shouldn't be discussing it here. TECHNICALLY we should be discussing it over on the SDL Hyperion issues page.

I apologize for sometimes coming across too brusque. I'm really not that type of person, even though it sometimes seems that way due to my poor choice of words, etc.   :)

We're good.   :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@marcoxa @Fish-Git @Peter-J-Jansen