How can i connect a folder in Delphi Library path to a folder in Subversion?
Background
In another Delphi source-control IDE plugin, you can configure what they call "Global Mappings". This means that an arbitrary folder on your hard-drive can be mapped to a folder in source control:
This means that any amount of arbitrary folder in my Library path, i can automatically get the benefits of source control:
get latest
merge changes
history
right from the IDE. The folders just contain arbitrary amounts of source-code files.
That's fine for Delphi 5
That works fine for Delphi 5, but what about Delphi XE6, and their built-in subversion client?
How do i specify a arbitrary mapping between a folder on my hard-drive, and a corresponding repository and folder on the network/internet/cloud?
Update: 3/6/2015
Epocalipse just released their updated VssConneXion for XE6! (and XE7, and their SourceConneXion for the same). Finally, i get to use source control in Delphi again!
It really would be super if Bo...Imp...Co...Embarcadero included some documentation on how to use SVN from Delphi. In the meantime, this question goes unsolvable.
From the image you've provide that other version control is SourceSafe and that probably means Delphi is talking to SourceSafe using the MSSCCI interface.
That would suggest that since Delphi supports MSSCCI, it should also work with any Subversion plug-in that implements the MSSCCI interface.
So one option would be to use Google and search for such a plug-in, of which there are a few to choose from.
I know of at least one such plug-in which is Agent SVN since I'm the author of that plug-in. But unfortunately I can't tell you if it works with Delphi as I've never tested it with that IDE.
But as the plug-in works with several other MSSCCI IDEs I suspect there is a good chance that it will.
Related
I've created some components in Delphi and I would like to give them to somebody else for use, but without source code.
I use the latest version of Delphi (10.2 Tokyo).
What are the steps I need to follow? Thank you!
If you want to share components in Delphi without source code, you must ensure that the other user has the exact same version of Delphi as you have[1]. This won't work with a different version. Note that it does not have to be the same SKU, i.e. you can have Professional or Community and the other can have, say, Enterprise. Only the version (e.g. Berlin 10.1, Tokyo 10.2, etc.) is important.
Then you can either
put them in a package and distribute the bpl and dcp files.
distribute the dcu files.
or both (preferrable)
Note that the user will have to install these. There are instructions in the help files on how to do that (no link, sorry, as the DocWiki seems to be down right now). Note that the package must be in one of the paths in the Windows DLL search order.
You could of course also write an installer, using one of the installer creating applications like InnoSetup (no association), but that is a topic of its own.
[1] That is the reason that many Delphi developers prefer components or classes with source and would not accept or buy one of these without source. Having the source also allows you to fix little bugs.
I'm trying to make a package for a custom component I made. It's based on several libraries, including Graphics32, GraphicEx and CCR.Exif.
I created a Package project, wrote the unit including its Register procedure, added some extra references Delphi notified me about to the requires section (including dbrtl.dcp, inet.dcp, soaprtl.dcp, vclimg.dcp, xmlrtl.dcp and dclGraphicEx140.dcp) and added many units to the contains section to avoid warnings about it happening implicitly. The project compiles and can be installed and used on my own machine without issues. However, when I want to install it on another machine, the troubles begin. In the end, I had to copy about all DCUs from all 3rd party components I used, plus both the DCP and BPL from GraphicEx, which I had to install even.
Supplying a lot of files is a bummer, yet surmountable, but having to install other packages as well is a no go. I could get rid of that DCP and BPL by putting even more units in the contains section, but that resulted in error messages on my own machine where GraphicEx is actually installed. This is confusing to me, because with Graphics32 nothing like that occurs...
Anyway, how do I keep my distribution to a minimum and avoid such situations? I want other developers on my team to be able to use the package without worrying about what I used to build it. For a start, can't all the 3rd party units be compiled into my own DCU?
What you experienced is an usual thing to the ones who write components. The distribution is always like that. Packages do not carry other packages, insted they reference them. It´s in their nature.
In order to overcome such a situation I always treat my components in the same way I would if they were a product to sell: I build a setup wizard that distributes and registers everything the package needs.
In my case InnoSetup works very well (http://www.jrsoftware.org/isinfo.php).
Summary
Haven't use Delphi for a while, but, did develop my custom visual controls (Last version I work was Delphi 6).
There are 2 issues when dealing with packages dependencies. One is installing at the Delphi enviroment, making controls appear on the component palette, plus, component editors & property editors.
And another when distributing the compiled packages into customers machines.
It also depends, on which version on Delphi you are running.
Design Time
When developing a custom package, there is a tab for package options, that indicates the destination folders.
The manuals usually tell the developers to leave those textboxes empty. That sometimes works, sometimes doesn't. I explicity write each folder path, in the respective textbox.
There is a textbox path for the ".dcp" files, other for the ".dcu", and so on.
If you have visual controls and stuff like property editors or component editors, its better to split the code in 2 packages ("Runtime" & "Designtime").
I usually put the delphi (packages) projects outside the delphi installation folder.
Run Time
Usually, the quick way is to put the "*.bpl" ".dcp" files in the Windows (32) / system folder, or similar "DLL" windows folder.
Packages folder structure source code suggestion
Managing packages can be difficult. I don't know how much the installation process has changed with Embarcadero, and the newer versions of Delphi. The following chart,is an example on how organize the source code. Hope it helps.
[-]--+--c:
.....|
.....+--[-]--+--software
.............|
.............+--[+]-----java
.............|
.............+--[+]-----php
.............|
.............+--[-]--+--delphi (not the delphi folder in program files)
.....................|
.....................+--[+]-----apps (source code for delphi programs)
.....................|
.....................+--[+]-----other
.....................|
.....................+--[-]--+--packages (all delphi packages source code here)
.............................|
.............................+--[+]-----lib (a single package for non visual controls, libraries)
.............................|
.............................+--[+]-----tools (package pair for non visual tcomponent descendants)
.............................|
.............................+--[+]-----json (example)
.............................|
.............................+--[+]-----xml (example)
.............................|
.............................+--[-]--+--mycontrols (folder custom visual controls)
.............................|.......|
.............................|.......+--[-]--+--delphi40 (folder for delphi40 version of "mycontrols")
.............................|.......|.......|
.............................|.......|.......+----------dsgvclctrls40.dpk (design-time package "mycontrols")
.............................|.......|.......|
.............................|.......|.......+----------runvclctrls40.dpk (run-time package "mycontrols")
.............................|.......|.......|
.............................|.......|.......+--[+]--+--demos (individual example for each "mycontrol")
.............................|.......|.......|
.............................|.......|.......+--[+]--+--design ("*.pas" component editors destination folder)
.............................|.......|.......|
.............................|.......|.......+--[+]--+--sources ("*.pas" source code destination folder)
.............................|.......|.......|
.............................|.......|.......+--[+]--+--bin ("*.dcu" destination folder)
.............................|.......|........
.............................|.......+--[+]--+--delphi50 (folder for delphi50 version of "mycontrols")
.............................|.......|........
.............................|.......+--[+]--+--delphi60 (folder for delphi60 version of "mycontrols")
.............................|.......|........
.............................|.......+--[+]--+--delphi70 (folder for delphi70 version of "mycontrols")
.............................|................
.............................+--[-]-----etc...
Cheers.
Thijs, you simply cannot do that with only a package. The target developer will require almost everything you added to the package. But there is an alternate way of doing what you want: Build a DLL with all the components/libraries you are using in your own component and wrap all those external components/libraries into some code you will export from the DLL. Then build your component without using the external components directly but the DLL you've built. You cannot in you component "use" any unit of the other external components/Libraries. You have to build a new unit with all the datatypes and required declaration for anything you export from your DLL. All this is perfectly working but will quickly becomes very complex for a large number of external components or libraries.
I think AlexSC has the best answer, but I think there might be an alternative if you ansolutely must have a custom component that has no dependencies.
I ran into the Delphi dependency frustrations a little while back trying to create an in-house component for our developers. My suggestion:
Uninstall all dependencies your component uses
In your component package, remove the above dcp from the requires section from your package.
Copy the source files of your dependencies to your components
When you distribute the component, you'll have to distibute it with the code of the required dependecies
You'll run into issues if you want to use the dependcies separately since Delphi won't allow you to have duplicate unit names in installed packages.
Also, the reason you don't want to use DCUs is the fact that the DCUs are compiled for a specific platform and compiler. So unless you are sure that all devolpers are on the same platform ad using the same version of Delphi, dependency code needs to be recompiled.
Again, AlexSC has the best answer and InnoStudio is a great little tool.
I bought Delphi XE2 Starter edition because I can't really afford the other versions and didn't really read the full spec sheet.
Now I find that my old Delphi 7 programs which use TAdoConnection, won't compile as ADO DB is not included in the Starter Edition (although I seem to recall downloading it seperately for Delphi 7).
I would strongly prefer to Download ADOB and install it - can I somehow?
If not, what are my free and low prices options for database access? Preferably ODBC, although I might be able to live with MySql only.
Update: I intend to purchaser AnyDac/UniDac/MyDac (the choice of which will be another question).
However, I couldn't help but notice that my own generic collection of functions is all in a single unit and if I link that unit's DCU with the XE2 starter edition, voila! I have d/b access in the Delphi XE2 starter edition.
There are some commercial data access packages you can get or perhaps this OpenSource one may work for you: http://www.productivity.org/projects/tmysql/
Some commercial options for Delphi and MySQL (and there is support for other databases as well):
http://www.devart.com/mydac/
http://www.microolap.com/products/connectivity/mysqldac/
http://www.da-soft.com/anydac/
AFAIK you can't download additional modules for Starter Edition (even for pay) from Embarcadero, you have to use some thirdparty solution which doesn't depend on TDataSet (as AFAIK it isn't included in Starter Edition). Some options are
KADAO - if you want to stick with ADO;
ZeosLib - open source, supports MySQL, PostgreSQL, Interbase, Firebird, MS SQL, Sybase, Oracle and SQLite;
UIB for Interbase and Firebird;
If you have the starter edition, you can use ZEOS access components.
You can download the XE2 package from SVN.
That's a bit fiddly, so in case you are unfamiliar with SVN here's a step by step.
Download a SVN client: http://tortoisesvn.net/downloads.html
Create a new folder to put the ZEOS components in; I use c:\borland\ZEOS
Right-click, and choose Tortoise SVN from the menu, then checkout or add.
copy paste the following url: https://zeoslib.svn.sourceforge.net/svnroot/zeoslib/branches/testing
There's a minor bug in the sourcecode that prevents it from compiling, see this answer how to fix that: https://stackoverflow.com/a/8389516/650492
As per usual you'll have add the directories the source code resides in to the search path, see: How to correctly set "Directories/Conditionals" and "Library" path
Just a quick question for those of you that know. Is it possible to have both Delphi (ver 7) and Lazarus installed at the same time. I want to make sure the Lazarus install will not interfere with my current Delphi install in ANY WAY. I would have asked this on the Lazarus fourms but thought I would get quicker reply here.
Anyway if you have both Delphi & Lazarus installed please tell me any problems you have encountered (if any) thanks.
Chris
Lazarus does not interfere with any version of Delphi, they can live along very happily.
The only interference is for commandline building, both projects have a make.exe file which are not the same.
This is easily solvable by not adding FPC to the path (removing it via control-panel system), and do a
set PATH=c:\fpc\2.5.1\bin\i386-win32;%PATH%
or wherever you installed as first line in your batch files.
I generally don't bother, but a previous employer we did a lot of cmdline building with dcc, and then it matters.
File associations are another, but already named. (but not such a big problem since the project extensions vary (.dpr vs .lpr, .dproj vs .lpi) )
Btw: Other development products (cygwin,mingw, and maybe even VS) have their own respective make.exe files and the same kind of problems.
I currently have Delphi 5 and Lazarus both installed on my Windows 7 laptop. As near as I can tell they don't interfere with each other.
I don't really use Lazarus though, as I prefer Delphi 5 which is what I've used forever.
I have Delphi 2006, Delphi 2010 and Lazarus installed. No problems at all. I am sure Delphi 7 will be the same. The only problem I can see could be the use of .pas extension in Lazarus. I mean because of association problems. But you can use a different extension for Lazarus (free pascal) source files. I think the installer asks you that.
I have Lazarus "installed" on a USB drive. It interferes with nothing whatsoever. It is actually a checkout of the Git repository that mirrors the SVN repository. I installed the latest stable FPC to C:\FPC, and then copied that folder to inside my lazarus source folder, e.g. \lazarus\FPC\ (and then uninstalled the C:\FPC installation), and then whenever I like I build the latest lazarus like this:
X:\lazarus\> git fetch
[...fetch messages...]
X:\lazarus\> FPC\2.4.0\bin\i386-win32\make.exe clean all
[...compiler output messages...]
X:\lazarus\> startlazarus
[...IDE starts up...]
The main advantage of this is that if you find an IDE bug, the source is immediately available and you can make and submit a patch instantly.
Since Indy is now built-into the install process of Delphi 2009... is there a proper way to 'remove' it so it can be upgraded to the latest from the SVN repo? There isn't an automated option to remove it as far as I'm aware.
The dcu files for Indy are stored separately from the other Delphi units. To stop using them, simply remove that directory from the search path, library path, etc., and remove the source files from the browse path.
You can remove the design-time packages the same as any other design-time packages. Remove them from the IDE configuration, and then delete the bpl and dcp files. (If you just delete the files, you may get errors when you next start the IDE since it won't find the expected files.)
Once the Indy components no longer appear on the Tool Palette, the packages no longer appear on the package list, and compiling a project that references Indy units fails with a "can't find used unit" error, you're ready to start installing the latest version.
As Rob already said: Just remove the direcories from Delphi's configuration. An additional step is required though: After each update, make sure they have not been added again! Some of the Delphi 2007 updates apparently did that and I missed it for quite a while until I stumbled upon a bug that I already thought fixed.
I didn't use Delphi 2009, but in older versions of Delphi the installation of Indy components was optional. So you could try launching the setup for Delphi 2009 and see if there is an option to "Add/Remove features" or something similar and use it to remove Indy.
Also, you can customize which packages should be loaded in a project, so you can simply deselect the Indy 10 one and add the one from SVN on a per-project basis (you can also configure the default configuration for projects).
PS. Indy rocks! :-)