kas1e / Odyssey

AmigaOS4 version of Odyssey
9 stars 7 forks source link

Set SDK paths in variables on cmake #19

Closed walkero-gr closed 4 years ago

walkero-gr commented 4 years ago

Is it possible to set SDK paths in variables in cmake, so to make the development environment more dynamic. What I mean is to keep the AmigaOS SDK separated from the extra Odyssey SDK, and their paths to be configured in variables, maybe inside amigaos4.cmake file.

This way the build of Odyssey would be more flexible, with no bondage on specific web environment and people can configure it as they prefer.

Can someone please point me were exactly I can set the SDK path, so to experiment with the above? For example now, when I do make Odyssey -j4 I get the following errors:

make Odyssey -j4
Scanning dependencies of target wtf
[  0%] Generating ../../generated_sources/JavaScriptCore/LLIntDesiredOffsets.h
offlineasm: Parsing /opt/code/Odyssey/odyssey-r155188-1.23/Source/JavaScriptCore/llint/LowLevelInterpreter.asm and creating offset extractor /opt/code/Odyssey/odyssey-r155188-1.23/build/generated_sources/JavaScriptCore/LLIntDesiredOffsets.h.
offlineasm: Including file /opt/code/Odyssey/odyssey-r155188-1.23/Source/JavaScriptCore/llint/LowLevelInterpreter64.asm
offlineasm: Including file /opt/code/Odyssey/odyssey-r155188-1.23/Source/JavaScriptCore/llint/LowLevelInterpreter32_64.asm
offlineasm: offset extractor /opt/code/Odyssey/odyssey-r155188-1.23/build/generated_sources/JavaScriptCore/LLIntDesiredOffsets.h successfully generated.
Scanning dependencies of target LLIntOffsetsExtractor
[  0%] Building CXX object Source/JavaScriptCore/CMakeFiles/LLIntOffsetsExtractor.dir/llint/LLIntOffsetsExtractor.cpp.obj
In file included from /opt/code/Odyssey/odyssey-r155188-1.23/Base/config.h:6,
                 from /opt/code/Odyssey/odyssey-r155188-1.23/Source/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp:26:
/opt/code/Odyssey/odyssey-r155188-1.23/Base/debug.h:5:12: fatal error: proto/exec.h: No such file or directory
   #include <proto/exec.h>
            ^~~~~~~~~~~~~~
compilation terminated.
Source/JavaScriptCore/CMakeFiles/LLIntOffsetsExtractor.dir/build.make:84: recipe for target 'Source/JavaScriptCore/CMakeFiles/LLIntOffsetsExtractor.dir/llint/LLIntOffsetsExtractor.cpp.obj' failed
make[3]: *** [Source/JavaScriptCore/CMakeFiles/LLIntOffsetsExtractor.dir/llint/LLIntOffsetsExtractor.cpp.obj] Error 1
CMakeFiles/Makefile2:144: recipe for target 'Source/JavaScriptCore/CMakeFiles/LLIntOffsetsExtractor.dir/all' failed
make[2]: *** [Source/JavaScriptCore/CMakeFiles/LLIntOffsetsExtractor.dir/all] Error 2
make[2]: *** Waiting for unfinished jobs....
kas1e commented 4 years ago

Your error points out that you just didn't install SDK at all on your cross-compiler. Or you install it, but forget to make the necessary final step. Your issue there is nothing we need to worry, but on your side, all steps for usual installation of SDK on cross-compiler should be done :)

As I wrote in my article on os4coding:

Once you build cross-compiler, all that you need is just issue our magic "export PATH=/usr/local/amiga/bin:$PATH" so Cygwin will know where to find amigaos4 compiler binaries / includes / SDK and stuff.

And!NOTE! be sure you add that line to the /home/user/.bashrc file, so you will have no needs to worry anymore about it, and it will be auto executed all the time you run your Cygwin shell.

That for any cross-compiler, not only for Cygwin.

But is there a reason why you worry ?:) I mean, it's all about that "docker" stuff no-one from programmers who already work on it needs it ?:)

walkero-gr commented 4 years ago

@kas1e Thank you for your help. The

export PATH=/usr/local/amiga/bin:$PATH has to do with the extra compiler binaries and not with the SDK. My proposal above doesn't have to do with the environment but with the code, and the flexibility it provides. In my opinion, hardcoded paths should be avoided, as much as possible.

Yeah, it is about the docker environment I am building, although as I explained, this issue here doesn't have to do with the development environment.

The deference between docker and any other dev environment, is that with docker, if someone wants to compile Odyssey, the only thing he will have to do to set up his development environment will be the following steps:

  1. install docker (https://docs.docker.com/desktop/)
  2. Open a terminal and run docker run -it --rm --name odysseyondocker -v "$PWD"/code:/opt/code -w /opt/code -e ODYSSEY_INC="/opt/code/Odyssey/odyssey-r155188-1.23_SDK/SDK" walkero/odysseyondocker:latest /bin/bash

The above steps are the same no matter the OS you use (Windows, MacOS, Linux). I find it much convenient, and I try to provide that solution to anyone who wants to use it. If people don't want to use it, it is fine with me.

walkero-gr commented 4 years ago

On the other hand, have in mind that if you want to implement a CI/CD setup for the project, to automate a few jobs, a docker image that compiles or runs the tests for the app is really easy and fast to be used.

This way you can have a server running automatically a bunch of tests or build the application, whenever a new push happens. Also, you can even automatically package and deploy the app whenever you create a new release tag at the github. Things like that cannot be done with the local Cygwin or MSYS2 environments.

My target is also to provide such solution for the project. If you and the rest of the team wants to use it, that would be nice. If not, that would be fine as well.

Those are the things I can do to help and contribute. I am sorry I can't do more.

kas1e commented 4 years ago

Basically those ones who want to works on, already do so. So IMHO be it docker or not will be not of big help. Everyone who wants already in and already can build it.

As for all the automatic releases and stuff, that also not of big issues. Things didn't happen to be released that often, that there any needs for automating things. And I basically love to make releases manually, it takes some time to put some love in :)