I have two conditions, one is electron is able to fetch files before electron has packaged. But I am not able to fetch the same files after electron has packaged.
For Example, I use path.resolve to .ini file present in parent directory. When I build electron package it is built two directories below. And I want the built package to still use the same .ini file.
path.resolve(__dirname,'../design.ini');
**Pre Package **
C:\cygwin64\home\xyz\Dev\xyz\abc\parent_dir\design.ini
**Post Package **
C:\cygwin64\home\xyz\Dev\xyz\abc\parent_dir\win64\abc\resources\app.asar\design.ini
Please not I build with asar enabled, Since the paths are different between pre and post, files are not fetched
I use `path.join`` and specify the specific path for internal assets – since I know it in advance and it isn't going to change:
var p1 = path.join(__dirname,'preferences", 'design.ini');
Haven't had any problems – even with asar enabled.
Did you try to use app.getPath() instead of path.resolve(...) ?
Related
I have have library with an artifact: src/lib/prelude.kind that I'd like to access. However, when I call the library code from a different project (which has the library set up as a dependency), the file src/lib/prelude.kind doesn't exist.
I can solve this problem by hardcoding the file location as _build/default/lib/kind/src/prelude.kind instead, but I'd rather not hardcode the Rebar3 default profile path.
Is there a way to refer to _build/default/lib or whatever the current profile location is from Erlang in a Rebar3 project?
You should use code:lib_dir/2
I'd make sure that the file is available with rebar3's artifacts (and move it out of the src subdir)
I have studied https://blog.bazel.build/2017/02/27/protocol-buffers.html . The project I want to hack on is written in Go. At the moment, if I run the build command I can see the compiled binary but I don't see the *.pb.go files anywhere. I want to keep the generated *.pb.go files in the same folder where *.proto files are so that my IDE (Intellij Goland) can find and index them.
Can you please help me how to get this working? If you can show me how to do that for the github.com/cgrushko/proto_library project, I should be able to try that in my particular project.
Bazel will not output generated files (such as .pb.go) into the source tree. They go into the output directories (bazel-out/<config> or bazel-genfiles/<config>). Temporary solution might be to add those as source roots to goland. The real solution is to use https://ij.bazel.build/. It has some Go support, and the team is actively working on improving it.
I am trying to install GLscene but getting problems with the source file locations.
It says in the install instructions to add the GLscene source directories into the global library path in tool/options/Delphi options/Library, which I have done but it has no effect.
I can add the source directories into each package project directory and it then compiles, but I would rather have it accessible globally.
The GLscene library items I have entered are,
C:\Users\Andy\Documents\Embarcadero\Studio\Projects\GLScene_VCL\Source
C:\Users\Andy\Documents\Embarcadero\Studio\Projects\GLScene_VCL\Source\Shaders
C:\Users\Andy\Documents\Embarcadero\Studio\Projects\GLScene_VCL\Source\DesignTime
Which are all correct,
anybody know any reason why the compiler can't find the files in these directories?
The compiler will search for source files on the library path. Note that there are separate library paths for different targets, e.g. Win32, Win64 etc.
If you have source files that cannot be found, then they are not in the library path that you specified.
Personally I don't like the approach of using search paths for source files. I like everything under my project directory so that I can check out from my VCS and have everything I need to build right there. A search path based approach makes serious development very difficult because you cannot maintain branches. What if you have old versions to maintain that use old versions of your libraries?
Well this is a bit late but it could help someone else.
Try and add the paths to both the Library Path and the Debug DCU Path.
Recent Delphi versions have different build configurations for Release and Debug and my guess is that the Debug configuration only searches in the Debug DCU Path.
I'm want to compile meshlab(http://sourceforge.net/p/meshlab/code/HEAD/tree/) and put the generated file outside the source directory to keep the source clean. Is it possible to just specify a build directory as the way in cmake?
The answer in this post Qmake and Make using separate folders for sources and headers, requires to modify the .pro file and doesn't work in my case. Users may want to specify the build dir path as they like, right?
I think what are trying to do is a QMake Shadow Build. This question about Manually Configuring Shadow Builds in QMake should help you.
I have (quite a bit of) static files that I need to deploy with my application that is built on top of a legacy .NET library. These include several XML and config files, and a read-only database in the 10's of Megabytes.
Most forums I have seen indicate that the best way to accomplish this is to reference the needed files in a project, and set them to Content and "Copy to Output Directory".
I have two issues/questions dealing with this:
Adding these files, and setting them to "Content" seems to not only copy the files over, but embed them into the .dll as well. In other words, I have 40 MB worth of files, and a 40MB dll (this project's only goal is to import these files, there is no substantial code).
How can I prevent this extremely large dll from being made?
Is there an alternative way to get files into the App bundle? I would love to use a custom build command, and although I can copy files into the target directory ${AppDirectory}, but this does not result in these files ending up in the app bundle. Is this approach possible?
Any help is appreciated in advance.
You need to include your files from the main .exe project. You do this by using MonoDevelop's Build Action to Content on each file. They should be copied to the .app without being included inside an .dll (or the .exe).
An alternative (for development) is to use iTunes sharing to copy once your files to your device. This allows you much faster deployment times while developing.
Of course you can't submit such build to the app store (unless the files are not required to make the application work, unlikely). What I do (for my nearly 80MB read-only database) is to use this hack (loading from /Documents) inside #if DEBUG. The release build load the files from the normal location.
I have not automated the process (still debugging the app ;-) but it should be possible to script this so modifying the project options (for each file) is not required when switching from Debug and Release builds.