After a few days of boredom, cleaning, and testing that things compile as expected, I upload latest sources of OS4 version of Odyssey on Github.
But before you go on, plz read this:
Please _NO_ other-browser release-forks!
You can't just change a few bits there, and release another "some_browser". By doing this you kill all motivation to continue working on. WebKit is free, but all Amiga (GUI and stuff) specific code there are hard work of some peoples (Fab, Joerg, DeadWood, Daniel_onyxsoft & Kas1e), who do not want situations when a source is taken, some things changed, and released like some other browser with some other name. So please respect that even if you didn't like.
If you wish to fix and improve things there, all should be put back to that repo, so later another version of Odyssey can be released.
All help appreciated, be it pull-request, patches, forum topics or whatever, but please no release-forks of Odyssey, calling it "somename_Odyssey" or "some_other_browser". If you wish your own browser and control how things should be done, just take WebKit source code and do whatever you want with taking those amiga-specific parts from Odyssey as reference.
And of course, it is absolutely not allowed to take that code, and making commercial releases of all sorts, be it Enhancer, OS4, or whatever else.
Probably there weren't big needs to explain an obvious, but just in case someone will find the idea of taking it all, changing a name, few bits with build date and made another "browser" as something worthy. So please NO. Thanks!
Currently, I in process of creating the "SDK" archive with all necessary includes and 3d party libs need it to make it all compiles and links, I hope today/tomorrow will be done with.
The source code uploaded done to be built on GCC 8.x, but with some very small changes, it can still be built on 4.4.3. But 4.4.3 are past, so today we on 8.x
Through switching to GCC 8.3.0 bring a new bug that needs to be dealing on before new beta-release (that one can be discussed in the 1.23 progress thread).
If you have any question about "how to compile", or you tried to compile thing but fail somewhere, feel free to ask. But firstly read that "HOW_TO_BUILD_AMIGAOS4.txt", it has some initial information already.
All the new fixes and stuff can be discussed in the 1.23 progress thread, or on Github, whatever way you find easy.
That version probably are stop-gap solution, until i didn't make fresh port of 1.25 from Deadwood's repo. But fixing this one are for sure good idea still. Basically cleaning of things there, can be just reused later in the 1.25 part and later if/maybe with new webkit based browser. But as 1.25 or new browser may happens a lot later, it better to have fix things there for now. I for myself will be happy if we all can do that:
1). clean the amiga code (i don't mean adding IFACE-> everywhere, that work for nothing, USE_INLINE works for now, and for easy porting process of new versions its easy to keep USE_INLINE). 2). fix the crashes on exit happens in javascript core when we on debug-kernel 3). add accelerated video playback (even if youtube says it will soon stop support that browser, we probabaly may cheat it somehow later anyway) 4). enable webgl maybe via opengles2 (through i not sure if in version we have it possbible. At least with 1.25 version it should be possible later, or if we will update webkit core in 1.23).
Edited by kas1e on 2020/2/28 19:06:51 Edited by kas1e on 2020/2/28 19:11:48 Edited by kas1e on 2020/2/28 19:13:35 Edited by kas1e on 2020/2/28 19:13:56 Edited by kas1e on 2020/3/1 7:58:51 Edited by kas1e on 2020/3/1 14:21:15
And so, WTF_OS_MORPHOS taken everywhere while builds, and no build scripts brokens, etc. And then change the things which need to be changed if compilationg borks, etc. Initially Fab says that it will be easer, as code the same and can be shared. And i just left the way i do it from version to version, just to not loose time on changing names everywhere.
In other words, all the necessary amigaos4 specific code done via amigaos4 ifdefs in the code, but that MORPHOS switch is need it so build system will have no needs to be changed.
But sure, it all can be changed easy now. Expectually with github when it all cleaner now.
Oh that one lovely ! With 1.9 and 1.16 releases all was fine, but when we first time port 1.23 to usable form, there was some surprise like if we run like "run owb" , or "execute owb" or from amidock : all fine. But if we run just from shell, then quit and then run, there was DSI in threading process. That need because tc_UserData wasn't null at exit in the shell. There more info:
EDIT: Okay, the SDK with all dependencies isn't quite ready yet...
I currently installed a new version of Cygwin + adtools, then cloning repo as I wrote in the readme (there already some simple mistakes in the text, fixed), and start step by step adding necessary 3d party SDK files till Odyssey not builds.
So probably today will have everything ready and uploaded. I only hope that i not loose those last days for nothing, and in end something will come out of it.
ps. Those ones who will install lately adtools, should take care there is some error happens for few weeks, which can be easyly workarounded, so follow that thread: https://github.com/sba1/adtools/issues/81
SDK automatically will downloads when you just do "git clone https://github.com/kas1e/Odyssey.git", so all you need it to copy all the files over your AmigaOS4 SDK.
Through, you better have "Odyssey only" cross-compiler installation, as Odyssey uses some libs which are older than your ones may be in the SDK, as well as some of them have custom code added (like fontconfig, cairo, curl, etc). So if you do care to not overwrite some of your up2date 3d party libs, then create special Adtools install somewhere for Odyssey only.
How_to_build.txt also updated with all that and other info, and tested that all builds fine:
I retested it by creating new Cygwin installation (copying my os4coding article about how to install Adtools on Cygwin), installing latest Adtools 8.3.0 on it, then added few more packages such a "gperf" and "ruby" (i noted that all in the how_To_build.txt), then downloading whole odyssey repo (which now contain SDK), copy all the SDK files over amigaos4 SDK just as it, running CMake command (as shown in how_To_build.txt), then when all builds, compile manually main.cpp and link it together to the binary.
Bug with switching to GCC 8.x with "progdir:conf/" and "conf" part being trashed heavy still there in the repo, so need to be deal first to have the same 1:1 working build as it was with GCC 4.4.3.
If anyone will try to build the thing now it will be pretty helpfull to pinpoint if there is can be mistakes in my "how_to" and whole building process.
Thanks!
@PJS
Realistically I think nothing will come up from (but I do hope to be wrong), but at least now when anyone will ask "where sources so we can update MediaPlayer part", or "where is sources so we can fix crashes in javascript", or "where are sources so we can fix that and that": they all there, with all VERY easy build instructions as possible, with almost fully automatic build, and with everything absolutely tested/retested and uploaded together with everything it needs.
I even made some Q/A in the "how_To_build.txt", where put info where is media files placed, where are GUI files, where that and that, etc.
And at the end of all, all the os4 specific code can be seen from GitHub now, which is easier for everyone to understand what happens and where.
@All Removed from "how_to_build" __MORPHOS__ part when build main.cpp (for main.cpp it not need it). Also a bit cleaning CMAKE/AddGlobalCompilerFlags.cmake by removing some of my old -I includes. As well as update a bit more "how_To_build.txt" (and moving it to the root of repo) and add another SDK.txt in the root of repo, so things will be cleaner.
I'm attempting to build Odyssey right now. A few suggestions for the build instructions: 1. Tell people using Cygwin to use git from the Cygwin shell. Using TortoiseGit or the Windows git will convert line endings to Windows style CRLF, and then "lex" will fail 2. CMake complains about building in the root directory, and warns that a future release will turn that into a fatal error. So add the following to the CMake process: mkdir build cd build cmake .. \ <insert long list of cmake options here>
I'll let you know how building goes. It's at about 6% right now...
1. Tell people using Cygwin to use git from the Cygwin shell. Using TortoiseGit or the Windows git will convert line endings to Windows style CRLF, and then "lex" will fail
I will note that, but, in that "how_to_build.txt" i specially show that one should run "git clone blalbal" which mean all work should be done from the shell. In the part "=== Download Odyssey repo", there is even strings for copy+paste:
I may add note of course, that one should follow exactly to the things i wrote, and while that was obvious in hope everyone will follow exactly steps, but i can add note surely :)
Quote:
2. CMake complains about building in the root directory, and warns that a future release will turn that into a fatal error. So add the following to the CMake process: mkdir build cd build cmake .. \
Right! While those things weren't fatal for now and all still builds fine, things should be done correctly, and as you do surely right one and how should be done with CMake.
Will recompile whole odyssey now to check if all will be fine that way, and change how_to_build accordingly.
Quote:
I'll let you know how building goes. It's at about 6% right now...
Now all should be fine, up to 25% all fill be fast, then "Scanning dependencies of target webcore" on Cygwin will take about 20 minutes (at least on my PC), but on Linux also fast. Then up to 95% compilation of WebCore, and then latest 5% is amiga specifci gui and webkit specificcode (webkit-owb). Then just compiling main.cpp and linking together.
1. Tell people using Cygwin to use git from the Cygwin shell. Using TortoiseGit or the Windows git will convert line endings to Windows style CRLF, and then "lex" will fail
Naa, there is a setting for this (Settings -> Git -> Auto Crlf convert). IIRC it's set to don't mess around with the line endings anyway (I don't know about outdated TortoiseGit versions though), so there's no problem. I just checked with a hex-viewer, to make sure: line endings from the Odyssey repo are well preserved.
@kas1e Thanks a lot for all the effort! Funny enough I just saw that there was a huge, well, "discussion" on amiga.org where some people came up with the old "make AOS open-source, that would solve all problems" idea This here would be a nice test case for those claims. I'm not too optimistic though...
Funny enough I just saw that there was a huge, well, "discussion" on amiga.org where some people came up with the old "make AOS open-source, that would solve all problems" idea This here would be a nice test case for those claims. I'm not too optimistic though...
Its enough to see how opensourced AROS evolve : the same no developers, no users, and less progress. Add to that no leader(s)/coordinator(s) (even bad ones), so welcome to all sort of "distros" and unfinished state. And opening AOS code will made things be even worse, just few unfinished forks and nothing serius.
Opensourcing any big project usually solve nothing in amiga world as there just a very few developers left who want to spend all their time on anything and not just talking. Usually things will ends up with "cleaning" , like adding IFACE-> things , removing USE_INLINE, remove tabs, fixing build date, and then nothing else or real bugx fixed :)
But at least with Odyssey i know that there on amigans.net few capable os4 developers left who know how to do things, how to use github and stuff and _maybe_ something new can be done.
Right now need to fix bug which happens when switch from gcc4.x to 8.x which trashed pathes used from other that OWB threads, but that again mean that someone should spend time to understand how and from where called/used/etc :)
I tried to overview all inital bits in the "how_to_buld", hope that will make things more easy.
Naa, there is a setting for this (Settings -> Git -> Auto Crlf convert). IIRC it's set to don't mess around with the line endings anyway (I don't know about outdated TortoiseGit versions though), so there's no problem. I just checked with a hex-viewer, to make sure: line endings from the Odyssey repo are well preserved.
I think it defaulted to AutoCRLF on my machine. It's possible that I installed something else that set the LF=>CRLF as default, but I'm not sure.
I wish the AutoCRLF setting didn't exist. If I change it and forget to delete and recheckout a repository that used the old settings, then my next commit would be full of line ending changes.
@kas1e Quote:
Now all should be fine, up to 25% all fill be fast, then "Scanning dependencies of target webcore" on Cygwin will take about 20 minutes (at least on my PC), but on Linux also fast. Then up to 95% compilation of WebCore, and then latest 5% is amiga specifci gui and webkit specificcode (webkit-owb). Then just compiling main.cpp and linking together.
Good to know. It looked like it got stuck at that point (the "Scanning dependencies..." bit wasn't printed), so I restarted. Will leave it running this time...
Absolutely. Whoever came up with the idea to do such auto-conversions instead of telling people to use text-editors which correctly handle and preserve line endings is a strong candidate for a good amount of tars and feathers.
Quote:
If I change it and forget to delete and recheckout a repository that used the old settings, then my next commit would be full of line ending changes.
In TortoiseGit's dialog you can set it based on repo or globally. After all it's just an entry in the .git/config file ([core] section, autocrlf=false), unless there's a .gitattributes file with overruling definitions
Hit a few errors just after 26%. It's looking for cairo.h in the include root rather than cairo/cairo.h. After creating an include that #includes cairo/cairo.h, it complains about cairo-ft.h being missing.
I could keep adding includes in this way, but why am I getting these errors when you don't?
EDIT: Adding a cairo-ft.h => cairo/cairo-ft.h include allowed it to proceed until BCMediaPlayerPrivateMorphOS.cpp, where it doesn't like GetInterface()/DropInterface(): Quote:
In file included from /cygdrive/d/development/Odyssey/odyssey-r155188-1.23/BAL/Media/WebCore/MorphOS/BCMediaPlayerPrivateMorphOS.cpp:81: /usr/local/amiga/adtools8/ppc-amigaos/SDK/include/include_h/interfaces/ahi.h: In static member function ‘static AHIIFace* AHIIFace::CreateIFace(Library*)’: /usr/local/amiga/adtools8/ppc-amigaos/SDK/include/include_h/interfaces/ahi.h:19:31: error: ‘GetInterface’ was not declared in this scope return (struct AHIIFace*) GetInterface((struct Library*) _AHIBase, "main", 1, NULL);
Looks like __USE_INLINE__ didn't get set correctly...
@Hans You surely do something wrong and not how i wrote in how_to_build.
First idea come to me about is that you didn't install cross-compiler to /usr/local/amiga/ppc-amigaos as it should be.
Second one, is that you didn't install SDK files of odyssey in the way how they placed.
Third idea, is that you don't use big-fat CMAKE command as i show in readme, so it didn't include for example CMAKE/AddGlobalCompilerFlags.cmake , the first line of which for now are:
So, if you follow how_to_build.txt, you should have all SDK files be insalled in the /usr/local/amiga/ppc-amigaos/SDK/. And when you copy Odyssey's SDK, you should have :
/usr/local/amiga/ppc-amigaos/SDK/common/include/cairo directory, in which that "cairo.h" will be fine, if you follow readme.
Quote:
..... Looks like __USE_INLINE__ didn't get set correctly...
Stop stop ! Everything broken for you already. You should follow 100% how_To_build.txt. Be the same directories.
Also you should issue correctly CMAKE command with all the settings. In your case, if you want bulid it with "build" dir, then it now should be just like this:
You also should have CLEAN SDK53_30 install and on top of it add Odyssey's includes.
For me it seems that none of "cmake" files includes for you, because you issue wrongly cmake command and CMAKE/AddGlobalCompilerFlags.cmake didn't added, which have and include to "cairo" directory, and which have USE_INLINE as well.
You start to change the thing from beginig, but you shoud 100% follow how_to_build.txt. No other dirs anywhere, no different ways of build, nothing. Pure copy+paste and following on what i wrote : afte all will good, then you can experiment and doing all those different things.
Ah, I made a slight mistake in the cmake parameters when switching to using a build/ subdirectory (the CMAKE_MODULE_PATH was wrong). I've deleted and started from scratch, and __USE_INLINE__ is now defined correctly.
@Hans Yep, and now "cairo" also will be taken fine. Maybe you also didn't have that "scaning dependencies" words as well because things were broken without correct odyssey's cmake modules added.
And yes, you probabaly need to delete everything now, redownload odyssey's repo and start from scratch : because you may have issues called "you already build some of components with wrong options and will fail, even if you run CMake again".
Because as you can see, "cmake" directory have a lot of files, meaning all the different settings and options to webcore. And its only at beging was issue with single one, webcore then later will fail for sure as well as gui code too.
So better rm -rf whole odyssey directory, git clone again, and start from this.
btw, your little mistake show probabaly something intersting if we will start new browser : libwtf, javascript, etc : can be build almost "as it", without specific changes (at least for start). That how it was probabaly at begining when Andrea and later Joerg works on first versions of OWB.
EDIT: also added info about usage of cygwin's GIT and errors one may have with CRLF to "how_to_build.txt
Edited by kas1e on 2020/3/1 14:05:59 Edited by kas1e on 2020/3/1 14:31:49
I still hit the missing cairo.h error, but that's because my cross-compiler is in /usr/local/amiga/adtools8/ instead of where your instructions says it should be. A simple soft-link can work around that.
The build is continuing now, but it's getting late. I'll let you know tomorrow if it completed without any further issue. Looking good so far.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
This here would be a nice test case for those claims. I'm not too optimistic though... 
