Forum > General
Advice needed on creating a cross platform run time .lpk [SOLVED]
carl_caulkett:
I've just investigated the idea of having separate run-time packages: "caMidiMacRun", "caMidiLinuxRun", "caMidiWindowsRun". I've created "caMidiMacRun" and it includes all the files in the "caMidi" folder, but, for some reason the build is failing on the "MacOsAll" reference. Do I need to add something to the package's search path options to allow the use of "MacOsAll"?
I've attached the experimental version of the project with the failing package in the caMidi folder. Any idea, anyone? 🙏🏽
TRon:
--- Quote from: carl_caulkett on October 06, 2024, 10:19:50 pm ---It would help if Lazarus had a global unit search path that could be added to.
--- End quote ---
It is actually the FPC compiler that does that using the standard commandline options, see https://www.freepascal.org/docs-html/user/userap1.html (option -Fu).
Lazarus itself has specific project settings that allows the user to add custom parameters to a project (such as for example adding a custom directory to the unit search path).
If there is a (finished) package then such a package can be installed using the IDE and which allows for a project to include such a package (add dependency). the FPC compiler allows for something like that as well (for non GUI packages) using fppkg but hardly no-one seem to use that (and you can actually do without by adjusting the fpc.cfg file to include a 3th party package unit directory f.e. (using the -Fu option))
bobby100:
You do not need to go for a package at all costs.
I keep my units in one (central) directory, and in Project Options > Compiler Options > Paths I add the path to this directory and to each of its sub-dirs.
This works for you, locally, but not the best way if you want to publish your code. In such case, you need sub-dirs in your project dir, like you already have.
As for the package, you need one OS-independent unit, and that is the one you'll refer to in the package file.
This unit will have uses section with IFDEF for the OS-es:
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---uses blah...blah units,{$IFDEF darwin}darwin_midi_unit,{$ENDIF}{$IFDEF windows}windows_midi_unit,{$ENDIF}...After that, this unit should provide the API (procedures, functions etc.) to the app, and the sub-units (darwin_midi_unit, windows_midi_unit etc) should provide the underlying functions used by this main unit. In the best case, all the underlying units would have the same-named procedures, with the same argument types, so that you don't need to IFDEF in the main unit.
Example: main midi unit has procedure
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---procedure SetMidiBuffer(AVal: string);begin SetMidiBufferInSubUnit(AVal);end;and your both darwin_midi_unit and windows_midi_unit have the procedure SetMidiBufferinSubUnit(AVal: string), but each unit with its own code that is OS-specific.
The IFDEFs are respected at installing the package in Lazarus, so the compiler will not complain about windows_midi_unit if you install the package on MacOS.
carl_caulkett:
I've solved the problem, and, in the end, the solution was ridiculously easy. I moved the "caMidi" folder out of the project folder to a location parallel to my project folder. Then all I had to do was to add the non-os-specific units to the Files section of my project. It builds and runs, yay :D If I ever choose to distribute the "camidi" package (once it's grown to be a bit more functional, it'll still be a bit of a faff to install, but at least being in one place solved the maintainability problem.
I have to thank Bobby100 who answered me in the other thread on this subject. He mentioned the 'PSS-Revive" project which I git cloned. I didn't get a chance to run the project because there were too many 3rd party components that I couldn't find, and the projecy seemed to be for 32 bit systems? The important thing I did notice was the use of the units in the "../units" folder ;)
carl_caulkett:
--- Quote from: bobby100 on October 06, 2024, 11:43:00 pm ---You do not need to go for a package at all costs.
I keep my units in one (central) directory, and in Project Options > Compiler Options > Paths I add the path to this directory and to each of its sub-dirs.
This works for you, locally, but not the best way if you want to publish your code. In such case, you need sub-dirs in your project dir, like you already have.
--- End quote ---
You post arrived while I was posting my message! But thanks very much, it's a solution I can work with ;)
Navigation
[0] Message Index
[#] Next page
[*] Previous page