search

hercules-390 / hyperion

Hercules 390
Other
253 stars 70 forks source link

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

Open marcoxa opened 4 years ago

marcoxa commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

Hi

first of all and above all, thank you for SDL Hyperion.

I am just an hobbyist here. I am using the "stable" binary release from September 2019 (4.2.1.9826). It works like a charm and I generated a MVS 3.8j following Jay Moseley's instructions. There is buglet on Windows pertaining the printing of page breaks (^L) which hampers Jay's rexx code checks is certain cases, but no big deal (FYI: ^L should appear on a separate line; they do not necessarily on Windows 10).

I also was able to run MTS 6.0a on Hyperion SDL without any hitch. I will test VM (six pack) next.

As per the Windows tool chain, I am not much of a Windows developer (and even less of a mainframe guy). To recompile SDL Hyperion from sources I downloaded Visual Studio 2019 Community Edition and tried to find my way around it. Eventually I bumped in the missing Win32.mak (or was it Win64.mak?) glitch which has been reported for Hyperion SDL and many other projects. I did find the file and moved in the possibly appropriate folder on my machine, but then I hit some other issue and it was 1:30 at night and I had to go to bed :)

I know it's just me, but I usually do not like to backpatch things like this. So I apologize if I came out as too obnoxious. It would be great if somebody (I am lazy; plus I do have a day job :) ) could prepare a Visual Studio 2019 solution for Hyperion SDL which removed "old" dependencies from previous Microsoft setups.

In any case, Hyperion SDL is "just working" for me as is, and I had quite a lot of fun learning things I did not know.

All the best

Marco

On Wed, May 27, 2020 at 6:46 AM Fish-Git notifications@github.com wrote:

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,

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.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/hercules-390/hyperion/issues/284#issuecomment-634425357, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD5SWQLZE3BF6HLUXB7XJTRTSLKPANCNFSM4MLCZXVQ .

-- Marco Antoniotti Somewhere over the Rainbow

Peter-J-Jansen commented 4 years ago

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 commented 4 years ago

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:

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 commented 4 years ago

Thank you all.

I do understand all the above, as I too maintain open source code (albeit on a much smaller scale). I obviously did miss the WIndows XP configuration bit in VS 2019.

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

All the best

Marco

On Thu, May 28, 2020 at 4:33 PM Fish-Git notifications@github.com wrote:

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 http://www.softdevlabs.com/hercules-vs2015-build.html" 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 https://github.com/SDL-Hercules-390/hyperion/issues, AND NOT HERE!

Thanks.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hercules-390/hyperion/issues/284#issuecomment-635387257, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD5SWSQXVG7ECJSOENCCCDRTZY4TANCNFSM4MLCZXVQ .

-- Marco Antoniotti Somewhere over the Rainbow

Fish-Git commented 4 years ago

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.   :)