CMake 3.29 Native (OS4)

Do we need .unix files anywhere other than the cmake bin directory? I think I have one in my project directory but probably not my build directory.

[EDIT] Looks like I can answer my own question on this. I added a unix file in the build folder and it then runs but does very little except eat CPU. It created the CMakeFiles folder / drawer / directory and inside that the pkgRedirect directory, but didn't go any further. As far as I can tell there was nothing nasty going on except the process being difficult to kill because of the maxed out CPU.

I'm currently testing this with a very simple Hello World C++ file and a 3 line cmake file.

@MartinW

Quote:

This indicates, that you are not using the right version of clib4.library. This is the "old" behavior.

Quote:

So no Makefile?

ahhh, hang on - I downloaded the clib4 lib from GitHub and placed it in the bin folder but I may well have the older one in my system. Does the one in the bin folder not take precedence? I honestly don't know how OS4 works in that regard.

And yeah, nothing other than an empty folder. I had to kill it.

@MartinW

Quote:

Ahem - try again (by downloading), and this time place it in SYS:Libs/

You may want to backup any existing previous version, in case you should have clib4 apps with specific requirements.

Quote:

I just checked, and it doesn't. In fact, I never heard of any ways to reference libraries other than placing them in the Libs: directory. Obviously this is different for .so files, I think there is a hierachy of paths for this kind of reference. So you would think this kind of thing could be useful for .library files as well. If someone knows anything about the subject, feel free to add to the text.

@elfpipe

That's fine - I'll give it another go after work. Just my assumption based on other OS's I did read the instructions but when it worked, I wrongly assumed the bin folder was also OK. Completely forgot that I already had clib4 because my project uses Raylib which is built against it. If there's nothing special about this latest version, other than being a bit newer then that's fine. I don't think I've got anything else that's using Clib4 at the moment but I don't really know.

Ideally I'd like to build my project locally using this cmake and clib4 but I can't because the gcc in the SDK doesn't recognise clib4 as a valid runtime. Obviously I could rename clib4 to clib2 but that's not a great idea. I've already demonstrated my complete inability to remember when I've done stupid stuff.

@MartinW

The idea of an Amiga-type .library is that it can be opened shared by multiple processes, and still only one physical copy of the code is in ram (only the process' own instances of any variables are duplicated).

Therefore the normal rule is to put it in the system-wide location LIBS:.

But if you really want to, you can always make a local Libs subdir in your program directory, and then Assign ADD that to LIBS:. That is what e.g. MUI does.

(Hope I've explained this correctly and understandably.)

Best regards,

Niels

@nbache
yes, very clear and understood, thanks! Remebering it for next time however is another challenge

@elfpipe
Onwards and upwards! Of sorts. CMake doesn't just bail now, so I assume my libs are now sorted.

I have the following trivial CmakeLists.txt - trying to make a test as simple as possible:


I've never used cmake with C++ before so it's possible the "cxx" in the last line is incorrect, however, I get the following output.



Just to preempt the next question, here is my s:user-startup snippet:


I checked before adding that path, that in the unix environment echo $PATH did not return anything, otherwise I would have done something like setenv PATH $PATH:blah

I have verified from the command line that the paths (both OS4 and unix) do indeed match that, and also the assign is present. Also that gmake can indeed be found in that path (at /SDK/C).

Since I'm not cross-compiling, I shouldn't need a toolchain file, correct?

Apologies if this is more than you were barganing on when you asked if people could test it :lol I also sincerely hope this isn't more of my environment not being setup correctly as that's a waste of your time!!

PS: I did try to set CMAKE_MAKE_PROGRAM but it didn't help and that's not something that I've explicitly had to do one other platforms unless, iirc, cross-compiling.

Last one from me for tonight...

If I set the items cmake is complaining about on the command line, cmake get's further but ultimately fails on the simple program compile test. If I check the TryCompile folder after, it's empty so either this is a temporary folder, or maybe there's still a path issue? (Or a 'my environment' issue?)

Switched the code to plain C for now to make life simpler.

Hope this all helps...

@MartinW

Quote:

It does. :)

We are looking for the simplest possible setup, so you shouldn't have to add items to the command line. Remember though, that if you ran the cmake command previously on that folder, it will "remember" certain configuration steps (including that they failed). I can recommend running something like

delete #? all

in the build folder, before running cmake .. again.

@nbache

Quote:

The problem is that - for instance in cases like this, where there are multiple versions of a library (clib4.library), and different applications might need different versions of it - there is no option to have a local version that overrides the "public" version. If there was something like the sobjs: construction, where the binary loader (elf.library) first looks in a local folder (for instance appdir:libs/) and only if the library is not found here, it looks in the public libs: folder. Then that would be a solution to the dependency problem.

Of course you can specify a specific version, when you open the library. But when using clib4.library this is not a possibility (at least not from an application perspective), because you are not in control of the library opening code.

Just so you know, I was already removing the build folder between tries. So the result is as above. I’m by no means an expert when it comes to cmake, but I’ve definitely come across that one before :)

@elfpipe

struct Library *OpenLibrary(STRPTR, ULONG);
...
A full path name for the library name is legitimate. For example "wp:libs/wp.library". This allows the use of custom libraries without requiring the user to copy the library into the system's LIBS: directory.

so if you set a fullpath to clib4_lib then 1st it will look there (if not already in memory)

@MartinW

Quote:

Thanks! In the meantime, I did some calculations and figured out, that the problem is indeed a problem with symbolic links. I will test and turn the text and come up with a solution in a week or two.

@jabirulo

Quote:Yeah, but there's the catch, isn't it? If the library is already in memory, and you haven't specified a (minimum) version, you'll get the one in memory, even if you specify another path. At least I think so (in matters like this I'm relying on what I think I read/understood some time in the past rather than lots of practical experience ).

Best regards,

Niels

@nbache

Quote:

Now, I guess I am not too involved in clib4 development, but I guess one of the main goals must be to make a perfect library, that is immutable and clear and meets all your needs. In all other cases, there could be the possibility of different apps relying on different quirks of different versions of that library, and it would be impossible to meet those needs, unless the user could pick and choose.

Release 0.0.2a :

CMake 3.29 alpha2 on GitHub

Remember to get also the new version of clib4.library. Cheers!

@elfpipe

OpenLibrary is part of Exec.library, its not part of clib4.

How OpenLibrary / ramlib works is defined by the OS.
not by libraries you make. So, this is something for the ExecSG Team.
That’s unless you make a ugly patch.

In any case, I know you where able to make changes to elf.library, so perhaps you are on the inside, if you have the possibility to makes changes to, it, perhaps you can make OpenLibrary case insensitive, while your at it.

Just to report back that I got the new cmake working in the end. Now I need to spend some time testing it on more complex projects than hello world.

@MartinW

Please post a screenshot here.

Not sure if this is what you mean, or if you mean later when I test it against more complex projects, but here's where I'm at so far. The issue, rather embarrassingly was that when added the path to my startup sequence, I'd missed the forward slash in /SDK/C which is why it couldn't find make and wasn't producing any makefiles. Instead it got a SIGHUP signal.

In the end, it worked fine from an Amiga shell and didn't need me to specifically be in abcshell. All works very nicely so far. I'll report back if I run into any issues when adding more complexity.