I'am using flutter for desktop.
The release folder (flutter build windows) contains the executable, the dlls and a data folder with all my assets including icons. Is there a way to compile these assets into the executable to prevent them from being easily copied or stolen.
The assets section inside pubspec.yaml looks like this:
Related
I have an electron app that I want my users to be able to install. However, a dependency of this app is a C++ package that I have compressed in a .zip file. I need the user to unzip this file and put it into a certain directory under Program Files (target platform is windows). Is it possible to create an installer that both installs the electron app and contains a payload that it can unzip and put into that directory?
Yes, this is possible. An Electron app is just a bunch of files that you can package however you want. A great tool for packaging Electron apps is electron-builder
electron-builder uses NSIS by default to build Windows setups. It also provides a way to customize the NSIS script
If you want to include additional resources for use during installation, such as scripts or additional installers, you can place them in the build directory and include them with File. For example, to include and run extramsi.msi during installation, place it in the build directory and use the following:
!macro customInstall
File /oname=$PLUGINSDIR\extramsi.msi "${BUILD_RESOURCES_DIR}\extramsi.msi"
ExecWait '"msiexec" /i "$PLUGINSDIR\extramsi.msi" /passive'
!macroend
In your case, instead of extramsi.msi, you'll probably want to include 7zip standalone console version and your additional .zip file. You can use this custom script to extract this file to wherever you want
I am new to cocoa and mac development. I have written an application which is combination of objective-c using cocoa framework and backend written in C++ library dylib.
I am using xcode 4.6 and have the above two projects Cocoa app and my C++ library. C++ is also my own project.
Now it is time for deployment. I want to make a pkg installer for it.
I could run/debug it in the xcode 4.6 because I had added search library path in the object-c project settings to be the output directory of the C++ project. Therefore it could find the dependency and run without crash.
Now in the Objective-C project tree inside the xcode I see products -> mysoftware.app file. if I find the location of this mysoftware.app file in the finder and run it, it crashes. I open the package contents of this app files and I see contentsfollowing structure
contents\(info.plist, MacOS, pkginfo, resources )
I do not see my C++ library in there, when I run mysoftware.app directly double clicking it crashes as it can not find the dylib I see the stack trace in the report window it can not find dylib, complaning that library not found usr/local/lib/mylib.dylib
I have also manually put the dylib file in the .app within the MacOS where my executable is, hoping that it will find the lib from the same directory, it did not , gave the same message above and looking from the the sane location /usr/local/lib/mylib.dylib
So my question is how do I resolve dependency of .app package for deployment, should I need to put the dylib inside the .app package ? how do I do that and then my next step would be to put this single .app thing in the pkg installer,
Thanks
This is what worked for me:
Drag the dylib into your Frameworks.
Add a Copy Files build phase, destination Frameworks and put the dylib there.
Add a Run Script phase which has the following script:
MYLIBNAME=libmylib.dylib
install_name_tool -change /usr/local/lib/$MYLIBNAME #executable_path/../Frameworks/$MYLIBNAME "$BUILT_PRODUCTS_DIR/$EXECUTABLE_PATH"
That's it. The script tells your app to load the dylib from the right place - otherwise it will complain about not finding the dylib at runtime.
Note that you don't need to change anything in the dylib itself - it could be supplied from elsewhere.
I resolved it so I am putting up this answer to help others who want to do the same.
The dylib has to go in one of the sub folders within the application bundle (i.e. mysoftware.app). Could be MacOS, Frameworks or any sub folder we decide to put it in.
The first step is in the target settings of our dylib, we set the install path to be relative to the app bundle (mysoftware.app), so in Xcode target settings of lib I set it to:
#executable_path/../frameworks
You can also use #rpath (You might want to research on that, I think it is more flexible than #executable_path)
Xcode will change the install name as well for our dylib.
Then in the Objective-C project using our dylib in the Project settings -> Build phases -> Link -> we drag our dylib here from the products node of the dylib project.
In the Objective-C/Cocoa project, the last step is to add a build step named copy files, and it should show a combo box telling you the target folder of the bundle. I set it to frameworks (this will depend on that relative path you choose when setting install path of your dylib) . The second part of the 'Copy Files' build step is to provide the souce file to copy. That's our dylib file that we want to pack in the bundle's Frameworks folder. So drag the dylib file from the products (of your dylib project) to the source file of the build step.
And that's it.
Now when we build the Objective-C or Cocoa project, if our build steps and install_path , etc are correctly configured, it should build fine. After a successfull build of the Cocoa project, go to Products -> mysoftware.app -> Locate in the Finder and when you run it, it should run fine. Since the dependency dylib is in the Frameworks folder of the bundle and correctly linked. You can see the package contents of the bundle to see if the Frameworks folder contains your dylib file.
To my surprise, the path where a dylib is stored has to be part of the dylib. So when a project links to this dylib it will copy the same path in itself, so when we run the Cocoa app which was linked to that dylib, it will look for it at exactly the same path which it copied from inside the dylib and we are responsible for telling the dylib where it exists. In the form of install_path, etc.
There are tools to manually update the dylib's install path stored in the Cocoa project using that dylib. If update the path of an existing bundle using these tools it should be changed in the client of the dylib, not required in the dylib itself.
If we've the code then we can change it in Xcode as instructed above.
otool -L my.dylib for example can be used to see the dylib install path of an existing binary lib
install_name_tool -change can be used to update the install path of existing binary lib
im trying to build an audio unit synth and I've got it to compile but and it works so far but I want to debug it properly by setting my daw as a debug exexuble. The problem is that the daw only loads plugings that are in the component folder and xcode says it doesn't have permission to build there.
You should set up a build step to copy the plugin from the built products directory to your components folder. Aside from the fact that the internal built products directory is internal, the AU tools on Mac will only look for plugins in the system and user components directories, unlike VST which can be an arbitrary path.
The script would look something like this:
cp -r "$BUILT_PRODUCTS_DIR/$PRODUCT_NAME.component" "$HOME/Library/Audio/Plug-Ins/Components"
Currently, I'm trying to figure out how to set up SDL with MinGW. I've seen a couple of sites that have methods (or rather, the same method re-published), but I'd rather not have a "quick 'n dirty" setup.
I see there's an sdl-conf file, I have MSYS installed, and I've downloaded the latest SDL 1.2 MinGW developer release.
The tutorial is here. It explains everything needed:
First thing you need to do is download SDL headers and binaries.
You will find them on the SDL website, specifically on this page.
Scroll Down to the Development Libraries section and download the Mingw32 development library
Open gz archive and there should be a *.tar archive inside.
Open the *.tar and there should be a folder inside of that.
Open the folder and it'll contain a bunch of subfolders.
Copy the contents of the lib subfolder to the MinGW lib folder.
The MinGW lib folder should be at C:\MinGWStudio\MinGW\lib.
After that, open the include subfolder in the archive and extract the folder named "SDL" to the MinGW include folder, which should be at C:\MinGWStudio\MinGW\include.
Note: Some versions of SDL won't have a folder named "SDL" in the archive's include subfolder, but just a bunch of header files. To get around this simply create a folder named "SDL" in your MinGW include folder and copy all the header files from the archive to that folder you made.
Now take the SDL.dll from the archive (it should be inside the bin subfolder) and extract it. You're going to put this in the same directory as your exe when you compile it.
Alternatively, you can copy SDL.dll to C:\WINDOWS\SYSTEM32 so your SDL app will find SDL.dll even if it's not in the same directory. If you're using a 64bit version of Windows, you'll want to put the dll in C:\Windows\SysWOW64.
The problem with this method is if you have multiple SDL apps that use different versions of SDL, you'll have version conflicts. If you have SDL 1.2.8 in SYSTEM32 when the app uses 1.2.13 you're going to run into problems. Generally you want to have your SDL.dll in the same directory as your executable developing and you'll always want to have SDL.dll in the same directory as the exe when distributing your app.
Now start up MinGW Developer Studio and start a new empty project.
Go to the project settings.
Under the Link tab, paste:
mingw32, SDLmain, SDL
in the libraries field.
Add source new source file to the project and paste the following code into the new source file:
//
#include "SDL/SDL.h"
int main( int argc, char* args[] ) {
SDL_Init( SDL_INIT_EVERYTHING ); //Start SDL
SDL_Quit(); //Quit SDL
return 0;
}
Now Compile. Save the new source file if necessary and make sure SDL.dll is in the same directory as the executable. If there are no errors, you're finished. Otherwise go back and make sure you didn't skip a step.
I have created my first XE2 FM HD application.
I have my OSX machine connected and running debug builds on OSX works fine, but I don't have a way to create a release version and copy it to another computer.
I tried just copying over the Package made by the debug but that's missing files.
Inside XE2 I went to Project -> Deployment.
For the OSX Debug deployment I have a green button, but under OSX Release deployment I don't.
Clues?
Here's step-by-step instructions for building the App bundle and putting in the required dynamic link library:
Create a folder called MyApp.app
Create a subfolder in Myapp.app called Contents
Create a subfolder in Contents called MacOS
Create a subfolder in Contents called Resources
From your build, copy Info.plist into Contents
From your build, copy the Mac binary to MacOS
From your build, copy the icon to Resources
Copy libcgunwind.1.0.dylib to MacOS
Copy the .app folder to your Mac and double-click it to run
You will find libcunwind.1.0.dylib on your Mac where you installed the platform assistant, most likely:
/Users/username/Applications/Embarcadero/PAServer/
Here's a video tutorial on how to create the manual install Disk Image installer on the Mac.