A task that I thought would be pretty simple turns out a bit more complicated.
I have a .json file inside my Kotlin Multiplatform module and I would like to share it between iOS and Android (to not include it for both platforms separately). My first naive approach was to add it into a folder inside commonMain. Well that did not work (accessing the file from the two platforms results in "null", but I am not even sure that the resource was bundled with the module).
Then I checked these instructions: https://luisramos.dev/how-to-share-resources-kmm,
also did not work.
I know about this library: https://github.com/icerockdev/moko-resources but I would not want to include a library just to share a file.
Is there an easy way to say "include this folder with all its files" inside the Multiplatform module and make it accessible for all platforms? (Accessing the file can be platform dependent, but just the file should be at one place)
Related
I am new to WebRTC stuff. I cloned the webrtc_ios main branch, and I built the framework as instructed here with the python script for arm64. When I add this to my Xcode project as a framework, everything is fine. Project builds, I can import files using <WebRTC/...> syntax.
However, I need to use RTCMTLRendeder.h file. Building a framework with python script leaves some of the header files out. (When I take a look at WebRTC.h inside the built framework, I can see that this file is missing) How can I include all header files that actually exist inside /webrtc_ios/src/sdk/objc/components folder while building the framework? I can see RTCMTLRenderer.h and .mm files are in that folder before using the build script. When turned into a framework those files don't exist inside the framework anymore. Why? And is there any other way to actually copy those files into the project as well?
Turns out you need to create your own, long renderer class which does not inherit from RTCMTLRenderer at all if you want to render on Metal view manually in a Swift/ObjC hybrid project (at least this is how I solved it). That class does whatever RTCMTLRenderer does, and grabs pixel buffers from RTCVideoTrack through an RTCVideoView.
I have created a Razor Class Library to be able to distribute some global styles and views across projects, but I can't seem to import my .less files from the Razor Class Library.
In my RCL I have:
Styles
-Shared
-layout.less
-variables.less
In the project referencing the RCL I have:
Styles
-main.less
main.less only has:
#import "./Shared/variables.less";
When I run a build via webpack I get errors that it cannot resolve ./Shared/variables.less, but it works fine if I copy the Shared directory from the RCL into the project referencing it.
I have the BuildAction for the RCL .less files set to Content, is there anything I am missing, or is this something that is not possible?
It's some what possible, but not for specifically what you're trying to do here. An RCL is ultimately a DLL, so the only thing you can include in it, is things that can be "compiled" into that. I say compiled with quotes, because static files can be included as embedded resources, so while they're not themselves compiled, they are still literally being embedded into the resulting DLL. With the ManifestEmbeddedFileProvider, the app using your RCL can read from these embedded resources as if they were literally on the filesystem.
However, and importantly, they are not on the the filesystem, which means using things like webpack is a 100% no-go. What you'll need to do is actually do a webpack build as part of the RCL, and then embed the resulting static resources in the RCL. Your app, then, can have its own webpack build for it's own resources, but you won't be able to combine primitives from the RCL with primitives from your app.
You could possibly manually manage the build order and run a powershell script post build (making sure that the correct dll is building first) and interrogate the dll and extract the required files (?) into the correct folders in wwwroot, or wherever, before the webpack build. I think that happens after the projects are built, but I'm not an expert on webpack either and I haven't actually tried this.
Also technically if you want any static or view files to be embedded in the dll you would select "Embedded resource", well that is how I've done it in the past.
I am trying to get this very small project working in intellij(it already works in eclipse). https://github.com/deanhiller/webpiecesExample which is generated from the webpieces webserver project. When booting the server, it can't find the html files in src/main/java(ie. the html files are there rather than src/main/resources to keep locality with their controllers).
I tried adding java:.html and java:.tag as I thought that would work according to this document
https://www.jetbrains.com/help/idea/2016.2/compiler.html
but that doesn't seem to work. I then also found cmd-; opens a window with resources and you can click on directories to mark them as resource directories. I tried doing that but it won't let me do that on a source directory.
Both gradle and eclipse are all working with this project, but I can't seem to get intellij working. It would be very nice to be able to use intellij on this project.
EDIT: Why put some resources in src/main/java instead of src/main/resources...
It can be very annoying to have to create the same package heirarchy in two directories(and slower as you are doing double the work). Also, you miss the view of controller's relationships to html files. Lastly, some files are referenced like ../example/index.html from the controller and literally it makes more sense to the user then if they are in the same tree. If you did ../../../../src/main/resource/com/buffalo/example/index.html, it actually would not even work as it is a relative classpath reference. After working in both environments, we found the one to be more efficient so even though it flies in the face of best practices, it makes developers faster(so best practices vs. developer speed.....I choose speed personally). BUT NOTE: This is not true on all projects. Most project should stick to src/main/java and src/main/resources.
thanks,
Dean
Up till this point in my programming career, I have mostly worked on small projects, editing the PHP/Perl/Python files directly on the Linux dev host, then copying the files to the same directory on a live server to push them into production.
I'm trying to set it up now by learning how to use Git and also how to properly write code with Git in mind. I want to learn the best practices for this scenario:
Here's a project called "BigFun", which also uses some libraries with tasks that are common to many projects.
/home/projects/BigFun/bin/script1.pl
/home/projects/BigFun/bin/script2.pl
/home/projects/BigFun/bin/script3.pl
/home/projects/BigFun/lib/FunMaker.pm
/home/projects/common/lib/Utilities.pm
/home/projects/common/lib/Format.pm
If this program is not managed by Git, and if I know that the files will never be moved around, I could do something like this:
#!/usr/bin/perl
use warnings;
use strict;
use lib '/home/projects/BigFun/lib';
use FunMaker;
use lib '/home/projects/common/lib';
use Utilities;
But once this is managed by Git, then anyone will be able to check these files out and put them in their own development space. The hardcoded URLs will not work anymore if your development rootdir is "C:\My Projects\BigFun".
So, some questions:
I can probably assume that the BigFun "lib" directory will always be relative to the "bin" directory. So maybe I could change line 3 to use lib '../lib'; . Is that the right solution, though?
It seems likely, though, that this example code I've listed would be split up in to two repositories - one for BigFun, and the other as a "common" repo containing some tools that are used by many projects. When that happens, it seems to me that the BigFun code would have no way of knowing where to find the "common" libraries. /home/projects/common/lib is not at all guaranteed to work, and nor would ../../common/lib. What's the normal Git way to handle something like this?
I'm working my way through the "Pro Git" book, but I haven't (yet) found anything to answer these questions. Thanks to anyone who can point me in the right direction!
Your question is not about Git,
it's about collaboration.
Absolute paths force all users of your piece of software to use the same directory layout, and that's unacceptable. No decent software does that.
Avoiding absolute paths in software is the norm,
regardless of what version control system you use, or not use.
How to make your software work using strictly relative paths and never absolute paths? That depends on the software/framework/language.
For relative paths to make sense,
you need to consider the question: relative from where?
Here are some ideas as the anchor from which relative paths could be considered:
current working directory
user home directory
package installation directory
framework installation directory
Every language typically has some packaging mechanism.
The goal of packaging is that developers in the language can create a standard package, the content of which is organized in such a way that the standard tools of the language can install it,
adding the software to the system-wide libraries of the language,
or to custom user libraries,
or to a specified library location.
Once the software is installed, from a standard package,
it becomes ready to use just like any other installed software.
In your example,
use warnings; and use strict; work without any setup because these libraries are installed in the system.
The system finds their location relative to the installation directory of Perl. Roughly speaking.
So what you need to do is:
Figure out how to package a Perl library
Figure out how to install a Perl package
Once your FunMaker and Utilities are installed as standard Perl packages, you will be able to simplify your script as:
#!/usr/bin/perl
use warnings;
use strict;
use FunMaker;
use Utilities;
You will of course have to document the dependencies of the script (FunMaker, Utilities),
as well as how to install them (especially the location where these packages will be hosted).
I have written a CMake module that contains a couple of useful macros that I would like to use across a number of other CMake projects. However, I'm not sure where to put the module.
I would like to be able to do this inside each project that uses the macro:
include(MyModule)
However, I'm not sure if there is an easy and cross-platform way of achieving this. In fact, I can't even get it to work on Unix. I put the module (MyModule.cmake) in the following locations:
/usr/lib/cmake/
/usr/lib/cmake/Modules
/usr/local/lib/cmake
/usr/local/lib/cmake/Modules
...and the project with the include() was unable to load the module.
What is the correct location for this module? Is there a better approach?
I should also point out that the macros are not related to "finding" a third-party library and therefore have nothing to do with find_package().
Put the module in a directory of your choice, and then add that directory to CMAKE_MODULE_PATH using list(APPEND).
You can even host that module somewhere and then download it via file(DOWNLOAD). If you download it to the same directory as the current CMake script being processed, you just include(MyModule.cmake) and don't need to modify CMAKE_MODULE_PATH.
You could download the file to a common location on disk and then add a check using if(EXISTS "${module_location_on_disk}") to skip the download if it's already downloaded. Of course, more logic will be required if your module changes, or you want to have a common location and multiple versions of the module, but that's out of those scope of your question.