I have a portable Electron program with a file tree that confuses some of my end users; is there any way to move the files to a different directory? I don't know what I need to edit in package.json (or other) to make it run.
Here's my current file tree:
current file tree
Potential solutions that won't work for my use case:
• mark directories as 'Hidden' - most users have "hidden files" on, so same problem
• create a .bat that targets the .exe - need to demonstrate how to start the .bat
• create a shortcut that targets the .exe - can use relative paths to target the .exe, but couldn't figure out how to target the icon
• recompile as a single .exe - need to frequently modify scripts/pages, so recompiling each time would be too time consuming
• manually create shortcuts for end-users - each app update would require me to ensure each shortcut is up-to-date
Any other suggestions would be greatly appreciated!
Related
I am using Dephi RAD Studio XE5 and creating a Firemonkey project that needs to run on android, ios, and win32.
I am trying to load a bitmap using BitMap.CreateFromFile(). I've added an 'images' folder to the project and stored the images in that folder. I've also added the images to the project so that they appear in the Project Manager view.
The problem is that when I try to use
TBitmap.CreateFromFile('images/myimage.jpg')
my app on win32 gives me the following error message:
Cannot open file "C:...\Win32\Debug\images\myimage.jpg"
Which suggests that the build process isn't copying the image files into the Debug folder.
How do I convince the build process to copy the images folder into the Debug folder?
edit:
Yes, I understand that computers aren't mind readers. :) Notwithstanding, when eclipse (for example) encounters a file in its src directory that it doesn't recognize as source code (like a .jpg or .xml) it will happily copy the file into the corresponding location in the bin directory. The underlying assumption is that the dev knows what they are doing. That's all I am looking for here.
I could use resources, but I don't like the idea of compiling images into my executable. Eventually, I'll want to change the images, perhaps having the app download additional images from a URL and caching them in the images directory. Who knows? Compiling images into an executable feels like closing the options box for future expansion.
Delphi does not do that for you automatically. You have several options though:
Copy the images to your output folder manually. Delphi will leave them untouched during the build.
Embed the images in your executable as resources. Then you don't have to provide the images when installing your application.
Use a build server such as Jenkins or FinalBuild to do the build for you. These tools are very flexible and allow you to do a lot more than just copying resource files in the right folder.
The build process won't copy your images files to the output folder. It is not capable of reading your mind!
If you want the files to be copied during the build then you'll need to add a pre-build or post-build event to perform the copy. The event might look like this:
xcopy /iy "$(PROJECTDIR)\images" "$(OUTPUTDIR)"images
As an aside, I think using TBitmap.CreateFromFile('images/myimage.jpg') is asking for trouble. That code assumes that the process working directory contains the images directory. That may be true, but is not guaranteed. If you wish to search for these files relative to the executable directory, you should build the full path yourself, starting from ExtractFilePath(ParamStr(0)). And personally, unless you have other reasons for deploying these assets as files, compiling them into your program as resources would be preferable. It makes deployment of your application simpler.
Simply I need output executable names like MyApp32.exe and MyApp64.exe after compiling my project in Delphi XE4.
I found a directive in the forum which is {$LIBSUFFIX '32'} but it seems it is only for dlls.
Any suggestions for executable files?
Thanks.
The final executable filename always matches the project filename. So either create separate projects that share common source code, or else use a Post-Build event to invoke a script that copies and renames the output file to a separate deployment folder after it has been compiled, such as:
copy /B "$(OutputPath)" "C:\Deployment\$(OutputName)$(MySuffix)$(OutputExt)"
Where MySuffix is defined in the Project Options with a different value for each platform:
MySuffix=32
.
MySuffix=64
By using a separate folder, the debugger still has access to the original un-renamed executable for debugging and testing.
Simple trick allow it:
Go to Project Settings->Application and in field "Target file extensions" add unique suffix for every configuration.
e.g
Debug 32 bit: debug32.exe
Debug 64 bit: debug64.exe
Release 32 bit: 32.exe
Release 64 bit: 64.exe
Output for project with name "ProjectName":
ProjectName.debug32.exe
ProjectName.debug64.exe
ProjectName.32.exe
ProjectName.64.exe
The way I handle this is that I have a single project with multiple targets: 32/64 bit, debug/release, etc. Each of those targets is output to a separate directory. For example, Win64\Release.
When I prepare the files needed for deployment and installation, I rename the executables at that point. And this renaming is needed because I deploy 32 and 64 bit versions to the same directory. Naturally this is all automated.
Remy's approach of renaming the output file as a post-build action has the downside that the debugger won't be able to locate an executable.
The philosophy is to fit in with the development environment when working with files that will be used by the IDE. But then when it comes to deployment, you are free to rename files, re-organise them into a different folder structure etc. that better suits your deployment needs.
I am attempting to install the IP3000 components into my Delphi 6 environment.
I figured I'd see if any of you have had experience getting it installed. From the files I have, there seems to be an installer missing (I have the UNWISE.exe).
I've tried including just about every folder in the environment's library path and browsing path and then build and install the packages (.DPK) with no luck.
Unfortunately, these Tww DB aware components are interleaved throughout my project so I can't get by without this package.
Any help is appreciated.
IME, most component install problems have some variation of the word 'path': Search Path (Delphi), Library Path (Delphi), System Path (Windows).
My advice is to put the *.bpl and *.dcu generated by the compilation in a path contained
in the Windows path (if you want to have some sanity on this, get the Rapid Environment Editor tool to deal with the Win path - which have a system one and user env one).
After dealing with that, install again. And:
Create a new vcl forms project
Put a random sample of their components on the form (if you can see then on pallete)
Press F9 to compile
So, if works, your install is complete. Don't try this with your own projects, as you can get nasty surprises when this fail....
This question is similar to this one, but not a duplicate because I'm asking about issues not discussed in that question.
I have a client-server project in Delphi 7 with the following directory structure:
\MyApp
\MyClientApp
\MyServerApp
\lib
There are 2 actual Delphi projects (.dpr), one each in the MyClientApp and MyServerApp folders.
The lib folder has .pas units that have common code to the client and server apps. What I'm wondering is if I should include those .pas files in the client and server projects? Or should I create a package in the lib folder which includes those units? Or should I just leave the .pas files sitting in the lib folder and not add them to any app/package?
What are the pros/cons of each approach? Which way is "best"? Is there any issue with having those units from the lib folder be included in more than one project?
Right now the units in the lib folder are not a part of any app/package. One disadvantage of this is that when I have my client app open in Delphi, for example, and I want to search in all files in the project for something, it doesn't also search in the units in the lib folder. I get around this by opening those units and doing a find in all open files, or using grep search (but I'd prefer a better solution).
I would also greatly prefer a solution where I will not have to go and open some separate package and recompile it when I make changes to those files in the lib folder (is this where I should use a project group?).
Sharing units between applications always carries the risk of incompatible changes done in one application that breaks the other. On the other hand, making copies of these units is even worse, so your approcach of moving them to their own subdirectory at least adds a psychological barrier to changing them without considering other programs.
As for adding them to the project files: I usually add some units which I frequently access (either for expanding or for reference) from the IDE to the project, and leave others out for the compiler to pick using the search path. I do that on per project basis, that means, some units may be part of several projects, why not?
Putting them into a package only makes sense, if you actually want to create a package based application, otherwise, why bother?
For more info on how I organize my projects and libraries, see http://www.dummzeuch.de/delphi/subversion/english.html
I dislike having files shared by projects. All too often, you'll be tempted to edit one of the shared files, and you'll either break something in the other project, or you'll forget that you have to rebuild the other project at all.
When the shared files are instead separated into their own library (package), then there's a little extra barrier to editing them. I consider that a good thing. It will be a light reminder that you're switching from project-specific code to shared code. You can use project groups to let you keep every together in a single IDE instance. arrange the library projects ahead of the executable projects. The "build all" command will build everything in order, starting with the first project.
Keep your DCU files separate from your PAS files. You can do this easily by setting the "DCU output directory" project option to send your package's units to some other location. Then put that destination directory on your other projects' "search path." They'll find the DCU, but they won't find the PAS file, and so no other project will accidentally recompile a unit that isn't really a member.
Having a separate package also discourages use of project-specific conditional defines. Those cause all sorts of trouble when you're sharing units between projects. Find a way to instead keep all project-specific options within the respective projects. A shared library shouldn't require project-specific modifications. If a library needs to act differently based on who's using it, then employ techniques like callback functions that the library user can set to modify the library's behavior.
I would need to have a very good reason to add shared code to a package. If you just have a few shared files stick them all in a directory called Shared. This should make it obvious the files are shared between projects.
Also use a good build tool to do automated builds so you will find out soon enough if you break something.
.bpl files are fine for components, but bring in serious added complexity for things like this, unless you have a huge amount of shared files.
I usually create a package with all shared unit, and just use the units.
If you do not explicitly mark "Build with run time packages" the package content (all used dcu's) will be linked to your project as any other unit.
I would only use runtime packages if you actually had two binaries that were supposed to run on the same physical machine and that shared some code. Keep in mind that runtime packages are mostly an all-or-nothing approach. Once you decide to use them you will also no longer be able to link the RTL and VCL units straight into your projects and will instead have to deploy those separately as well.
However, packages might still be a good solution to your problem when combined with project groups which is exactly what I'm doing. I hate having shared units included in multiple projects. Including the shared units in a package (but not compiling your actual projects with runtime packages) allows you to add that package to your project group so you (and the IDE!) will always have them easily accessible yet nicely separated from the project-specific code. Strictly speaking you don't even ever have to compile those packages. They can merely serve as an organisational unit in the project manager.
Note that for the Find in Files, you can also specify "in all files in project group"
I'm curious about everyones practices when it comes to using or distributing libraries for an application that you write.
First of all, when developing your application do you link the debug or release version of the libraries? (For when you run your application in debug mode)
Then when you run your app in release mode just before deploying, which build of the libraries do you use?
How do you perform the switch between your debug and release version of the libraries? Do you do it manually, do you use macros, or whatever else is it that you do?
I would first determine what requirements are needed from the library:
Debug/Release
Unicode support
And so on..
With that determined you can then create configurations for each combination required by yourself or other library users.
When compiling and linking it is very important that you keep that libraries and executable consistent with respect to configurations used i.e. don't mix release & debug when linking.
I know on the Windows/VS platform this can cause subtle memory issues if debug & release libs are mixed within an executable.
As Brian has mentioned to Visual Studio it's best to use the Configuration Manager to setup how you want each configuration you require to be built.
For example our projects require the following configurations to be available depending on the executable being built.
Debug+Unicode
Debug+ASCII
Release+Unicode
Release+ASCII
The users of this particular project use the Configuration Manager to match their executable requirements with the project's available configurations.
Regarding the use of macros, they are used extensively in implementing compile time decisions for requirements like if the debug or release version of a function is to be linked. If you're using VS you can view the pre-processor definitions attribute to see how the various macros are defined e.g. _DEBUG _RELEASE, this is how the configuration controls whats compiled.
What platform are you using to compile/link your projects?
EDIT: Expanding on your updated comment..
If the Configuration Manager option is not available to you then I recommend using the following properties from the project:
Linker->Additional Library Directories or Linker->Input
Use the macro $(ConfigurationName) to link with the appropriate library configuration e.g. Debug/Release.
$(ProjectDir)\..\third-party-prj\$(ConfigurationName)\third-party.lib
Build Events or Custom Build Step configuration property
Execute a copy of the required library file(s) from the dependent project prior (or after) to the build occurring.
xcopy $(ProjectDir)\..\third-party-prj\$(ConfigurationName)\third-party.dll $(IntDir)
The macro $(ProjectDir) will be substituted for the current project's location and causes the operation to occur relative to the current project.
The macro $(ConfigurationName) will be substituted for the currently selected configuration (default is Debug or Release) which allows the correct items to be copied depending on what configuration is being built currently.
If you use a regular naming convention for your project configurations it will help, as you can use the $(ConfigurationName) macro, otherwise you can simply use a fixed string.
I use VS. The way that I do it is that the libraries I need through the references of the project. Which basically just says in what folder to look for a specific library at project load time. I develop my libraries to be as project independent or reusable as possible. Therefore they are all projects of their own. So of the libraries that I need for a specific project, I create a "3rdParty" or "libs" folder at the same level as my "src" folder in my svn folder tree. I tend to only use released libraries, but when I get some unknown issues and want to switch to debug, I manually copy a debug version of the files in the "lib" folder and reload the project.
I am unsure wether I should be keeping both debug and released versions in my svn tree. Although since they are projects of their own, keeping them in the svn tree of another project doesn't right. They can be built again without an hitch at any moment.
And then I wanted to find a way of making the switch more...hmmm...well basically automatic if you while, but that's not what I really mean. It just feels that switching the files manually between released and debug isn't right. Maybe I haven't found it yet, but what I would like is an option that would do like:
For library "stack.dll" look in "......\3rdParty\" for release and "......\3rdPartyD\" for debug.
Anything that those something like I don't know. What do you suggest?
Remember libraries are external projects. There the built files are totally elsewhere. In fact think of it as you have to check out another project, build it, and copy the built library if you want another copy. How would you set that up?