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.
Related
I have installed Luadist and created a small program (named abcd.lua which also uses IUP GUI). It runs well with command iuplua.exe abcd.lua I want to give it to some other persons to try. Since Lua may not be installed on their computer, I want to give it to them with Luadist folder. I see that there are a large number of files in Luadist folder (1148 to be exact- tried listing them here but it exceeds character count). They are in following folders:
bin : has large number of exe and dll files.
include: has lauxlib.h luaconf.h lua.h lua.hpp lualib.h
lib: has liblua.dll.a and its extracted folder and a lua folder with large number of subfolders and files
share: also has large number of folders and files.
tmp: only empty cache folder currently
Following files contain 'iup' in their names:
./share/luadist-git/dists/iup-3.6
./share/luadist-git/dists/iup-3.6/dist.info
./share/iup
./share/iup/README
./share/iup/COPYRIGHT
./lib/lua/iupluaimglib.dll
./lib/lua/iuplua.dll
./lib/lua/iuplua_mglplot.dll
./lib/lua/iupluacd.dll
./lib/lua/iupluacontrols.dll
./lib/lua/iupluagl.dll
./lib/lua/iuplua_pplot.dll
./lib/lua/iupluatuio.dll
./lib/lua/iupluaim.dll
./bin/libiuptuio.dll
./bin/libiup_pplot.dll
./bin/iuplua.exe
./bin/iupview.exe
./bin/libiup.dll
./bin/libiupgl.dll
./bin/libiupcd.dll
./bin/libiupim.dll
./bin/libiupimglib.dll
./bin/libiup_mglplot.dll
./bin/libiuplua.dll
./bin/libiupcontrols.dll
Will giving only these file alongwith my program file (abcd.lua) be sufficient, though I think many dll files will also be needed?
Which files or folders can I select to give or do I need to give all files for proper running of my program? Thanks for your help.
In the IUP documentation, each library describes its dependencies. You can start there.
But the answer depends on what modules are you using. If the only "require" you do is "iup", then it is quite simple. You will need the executable, the Lua DLL, the IUP DLL and the IUPLUA DLL.
You have a couple of options:
(1) move the executable to a different folder and start your script. It will fails with an error message about a missing DLL; move the DLL to the folder with the executable and repeat. This should give you a list of the dependencies, assuming the execution will follow all code paths that load external modules.
(2) use the dependency walker to find all dependencies that your executable and its DLLs have. The advantage of this method is that you can execute it without moving any files and it will give you a detailed analysis of the dependencies and how they are resolved on your system.
Keep in mind that you don't need to preserve the same structure that LuaDist has for the dynamic libraries; you can put all the DLLs your script needs next to the executable (and this is likely to be the simplest and the most successful configuration).
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.
The software that I have found myself supporting, from time to time fails to run on different PC's. Generally they are new Win7 installs.
The error message is "this application failed to start because rtl90.bpl was not found..."
To rectify the problem I have out PC Support copy the rtl90.bpl file to the users system32 directory, however i would like to ensure this error no longer occurs.
I have googled and found the followling link rtl90.bpl problem
My question is this:
The option to "Build with runtime packages" is already selected under the Project options for this program, and does not appear to make any difference to the users getting the problem.
Do I have to specifically Add the missing rtl90.bpl file to the project?
Please note that I know very little about delphi programming.
Since you are marked the option Build with runtime packages in your project, the final exe will require be deployed with some additional bpl files. To avoid that dependencies you must uncheck that option y build your project. Now your exe wil be bigger but without dependences.
That package is a runtime package containing the VCL. You presumably also need to deploy rtl90.bpl for the RTL and possibly some others. By enabling runtime packages you are promising to deploy those packages where the executable can find them.
You have 3 main options:
Deploy the packages to a location that is contained in the PATH variable. Usually this means modifying PATH. You should never write to the system directory. It is owned by the system and you should respect that.
Deploy the packages to the same directory as the executable file.
Disable runtime packages and therefore build a single self-contained executable. The RTL/VCL code will be statically linked into your executable.
Option 1 is poor in my view. Relying on the PATH variable and the ability to modify it is fragile. Option 2 works but seems rather pointless in comparison with option 3. You deploy more files and larger files when you choose 2, so why choose it.
In summary I recommend option 3. Statically link all RTL/VCL code into your executable.
The only situation where option 2 wins, in my view, is when you have multiple related executables that are all deployed to the same directory. In that situation sharing the RTL/VCL code can make sense.
I want the exe name of an application given 'ProgramExeName + version number' at compilation time (exemple: Filename18190.exe, Filename18191.exe...) - so the exe name is never the same. Considering i have the version number put in a str variable, how to automatically append this number to the exe name currently built? Tx
(Note: i want the renaming be done at compilation time, not manipulated after)
There are several directives to manipulate the filename of output binary {$EXT string}, {$LIBPREFIX 'string'}, {$LIBSUFFIX 'string'}, {$LIBVERSION 'string'} (btw, compiler have nothing with with forming output binary, this done by linker). Neither of them is dynamic, so you HAVE to write desired values right before building your project (good job for OpenToolAPI wizard in the IDE).
The other possibility is post-build activity which extracts version number (for example: VERSION_INFO) from PE binary and renames the file accordingly
If it must be done by the compiler, then no, Delphi simply wont do that. The name of the exe is the name of the project. Run a batch file after the build (I believe later delphi's let you do this) and rename the file to whatever you want. You may need to create a seperate helper program to extract the build number from the program's resources so that you can use that in the name.
the filename is generated automatically from the project file, you can't change that. But look at post build events, maybe you can figure out something that changes the filename after a successful build
You could write a batch file / makefile / Rakefile / whatever that runs the compile steps and then just renames it according to the system time or something like that. Your question is a little vague, so it's hard to say precisely, but it's a thought.
There is no way to do that in Delphi for normal executables. For packages there is the LIB suffix option, which could probably be manipulated to do what you want but that won't help you.
Hm, thinking about it, maybe it would be possible to write an IDE addon that uses the ToolsAPI to save the project with a different name every time you do a build. You would end up with as many project files as executables. I don't know whether it can be done.
We create via "Tools | Options | Environment Variables" Variables like that:
$(Sources) = D:\Sources\Delphi
$(OurLib) = $(Sources)\OurLib\Src
$(OurApp1) = $(Sources)\Applications\App1\3.x
$(ThirdParty) = $(Sources)\ThirdPartyComponents
We use these Variables in the project search path like that:
($OurApp1)\Src\Core;($OurApp1)\Src\GUI;($OurApp1)\Src\Plugins;$(ThirdParty)\JVCL
But this is broken (meanwhile fixed) since Delphi 2009 as these variables are not evaluated completely anymore (see QC #73276). So the files in the directories are not found by the compiler. A workaround: Use only complete directories in the environment variables.
We use this approach because on all developer machines and the build servers the files can be found and we only have to point $(Sources) to the right place.
We don't have anything in our global library path (except the Delphi defaults), because that wouldn't be in the version control and isn't reflected on other developers or build machines.
One problem is: If one unit in $(OurLib) decides to include another new unit maybe in a new path, all projects break because they don't find this new unit. Then we have to go through all projects and add the search path. (BTW: I really hate the search path editor...wouldn't be a simple memo field much better to edit than this replace/add/delete logic?)
Another thing we do is not adding many units to our project. Especially everything from $(OurLib), but we often have units like plugins which add functionality only by including them. For different editions of our products, we want to include different units. As Delphi always messes up $IFDEFs in the uses clause in the .dpr we help us by including units named like "IncludePlugins" which then include the units depending on IFDEFs.
But not including units in the project makes navigating to a pain. The units don't appear in the project, they are not found by Ctrl+12 (Show Units), they are not shown in code completion etc.
Has anybody a better way to cope with these problems?
We use only relative paths, any libraries are always below the libs subdirectory while the project source code resides in the src subdir. So our search paths always look like:
..\libs\library1;..\libs\library2\common;
etc.
All libraries are added as svn:external to each project, so checking out the project will automatically check out the libraries as well and the search path will always point to the correct version of the library for that project.
Not perfect, but it works most of the time.
I have to agree about the search path editor, it is even worse for relative paths because you must not use the "..." buttons otherwise Delphi will insert an absolute path.
We use standard drive mappings.
Our current project is always on W: regardless if it is a network drive or a substitute.
This works great.
When you need to work on a different project, swap the W: and you can continue.
You can copy the search path out to an editor, modify it and then copy it back.
Your search path is much too big. It should contain only the things you want Delphi to recompile with your project. You don't really want to recompile the Jedi VCL every day, do you?
I create a single directory where all compiled units go. Say, C:\dcu. Specify that as the "unit output directory" in all packages. My "search path," then, is always just this:
$(Delphi)\Lib;C:\dcu
The compiler finds everything it needs, and it never finds any source code. The only source code it ever sees is in the files that directly belong to whatever project I'm compiling. The project's own source directories don't need to be on the search path because all of those files are already direct members of the project. The compiler knows exactly where they are.
For me, all a project's source files go in a single directory. If you want separate directories for different parts, like Core and GUI, then I would put those in separate packages so I could work on them and compile them separately. Even if the final program doesn't use the resultant BPLs, packages are still a good way of segmenting your project and defining dependencies.
When compiling units for one project doesn't automatically compile units for all the other projects, you're forced to change active projects. It takes a moment of your time, but it also serves as a mental reminder that you're "changing hats," too.
Although you're producing just one product, that doesn't mean you should have just one project in Delphi. You should have at least one project for each executable module (EXE, DLL, BPL) in your product. Use project groups to manage multiple projects in a single IDE session. No unit should be a member of more than one project.
I don't understand your part about plug-ins and different editions of your project. When you say "plug-in," I assume you're talking about separate executable modules, like DLLs or packages, that the customer can choose to include or not. Couldn't you turn your different editions' features into plug-in modules that simply don't include in the lesser editions? Then you don't have to worry about conditional compilation of your project; just have several different installer packagers that grab different sets of plug-ins.
I have always found it odd that this has never been addressed adequately. I suggested recently to David I that Delphi should allow the user to set up some sort of preferred development structure and that third party library publishers could be made aware of this so that they could automatically adjust their installers to install correctly in the preferred development framework. If the preferred development structure was stored in an XML file or similar, then, it could be copied from one computer to another on a development team.
As an alternative, it could make an interesting project to create a Delphi application that would allow a user to "refactor" their library installation in a high level way. You specify which folders on your system contain source or compiled components or whatever and where you want to keep source files or compiled units, hit Go and your system gets rearranged for you, while updating your Delphi environment so that when you start Delphi, it finds everything it should.
I've just recently discovered a way to have project specific environment variables in delphi builds using XE6, it's not quite as good as a full blown #define like in C but at least I can now have consistent search paths across multiple projects and create some shared option sets.
What I've done is setup environment variables in the same manner as the original poster and then override them in the dproj or optionset.
The BuildPaths.optset added to the project looks like
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<SVN_Root>..\..\..</SVN_Root>
<SVN_Riemann>$(SVN_Root)\Riemann</SVN_Riemann>
<SVN_Library>$(SVN_Root)\Library</SVN_Library>
<SVN_ThirdParty>$(SVN_Library)\Third Party</SVN_ThirdParty>
</PropertyGroup>
<ProjectExtensions>
<Borland.Personality>Delphi.Personality.12</Borland.Personality>
<Borland.ProjectType>OptionSet</Borland.ProjectType>
<BorlandProject>
<Delphi.Personality/>
</BorlandProject>
<ProjectFileVersion>12</ProjectFileVersion>
</ProjectExtensions>
</Project>