Strange bug under Seattle (not tested for older releases)
Strange bug under Seattle (not tested for older releases)
Create a new FMX project, save it and close it.
delete:
Project1.dproj
Project1.dproj.local
Project1.identcache
Open Project1.dpr
the available targets are now only Win32 and iOS64
add the Android platform and compile the project you'll have a compilation error with a C:\res not found error !
on C: you'll find
C:\assets
C:\bin
C:\classes
C:\debug
C:\library
C:\Project1
:(
Create a new FMX project, save it and close it.
delete:
Project1.dproj
Project1.dproj.local
Project1.identcache
Open Project1.dpr
the available targets are now only Win32 and iOS64
add the Android platform and compile the project you'll have a compilation error with a C:\res not found error !
on C: you'll find
C:\assets
C:\bin
C:\classes
C:\debug
C:\library
C:\Project1
:(
/sub
ReplyDeleteThis is by design (mostly). Before you shout and complain, allow me to explain why.
ReplyDeleteWhen the .dproj (and .cbproj for C++Builder) where introduced, not only where they intended for making command-line builds easier to do with Msbuild, they also allowed for much more information to be stored without cluttering up the .dpr files. As platforms were added, information about those specific targets were way out of scope for injecting into the .dpr (or .cfg).
The idea was that when you open up a naked .dpr file the IDE simply cannot determine for what potential targets this project was intended. We must assume that this is a very old, pre-dproj project and do our best to "upgrade" the project. Since pre-dproj days the only available target was Win32, that should be the only available target. (because iOS64 is available, that is clearly a bug in this logic. Thus my "mostly" comment above). The IDE simply cannot divine out of thin air where this project originated.
Suppose you opened an old Delphi 7 dpr... It would most likely be a VCL based project. Allowing the user to add OSX, Android or other platforms to said project would be strange and only confuse the user. They'd try and compile and immediately get errors about missing .dcu files.
So what is the upshot of all of this? Much like going to the doctor complaining about a pain in your arm when you twist and contort in an unusual manner and he merely responds with "don't do that". In this case, don't delete the dproj file, they're necessary and important.
Allen Bauer Agreed. Too bad that some people had the stupid idea to tell others not to publish or store dproj in VCS (https://www.delphitools.info/2011/11/10/dont-publish-your-dproj-groupproj/)
ReplyDeleteStefan Glienke I can understand some of that sentiment, however the solution isn't to simply toss them out. Ideally, only critical project items that makes sense for building the project should be in there. A lot of options only matter to an individual developer... debugging options such as the host application, command-line options. Certain states such as selected target or the active project in a project group are also only interesting to a specific developer.
ReplyDeleteI've long argued that there should be some project options that are only stored locally and a way to select other options to override locally.
Because of this, it makes it much harder to share a dproj among team members. I suspect this recommendation is a product of the less-than-ideal manner in which the dproj is used.
I think the dproj should finally be admitted in the "Delphi Project" pantheon. Remove all the "developer-specific" information and move them to the .local .
ReplyDeleteThe import wizard could actually ask which platforms you want in. That to me seems best. Less than best, but still way better than it is now, would be to have a select-able default.
Allen Bauer ??
A
Allen Bauer ok I understand, but when I add the Android platform, it should be ready to compile without sending outputs to C:\ ;)
ReplyDeleteBTW, under XE5 I've made a projet that can compile under all supported platforme, but the IDE won't let me define all those platforms, so there's something wrong in the way the dproj is handled. This is fixed in XE7 that merged FMX mobile & desktop, but the project need to be declared as FMX while it is not.
http://cc.embarcadero.com/Item/29684
Paul TOTH Yes, those are bugs. Please report this in quality.embarcadero.com.
ReplyDeleteAndrea Raimondi Why ask questions that the user may not be able to answer? Something like that would quickly devolve into "I don't know... so I'll pick them all". Then later, they'll have the nerve to be surprised with their VCL Windows app won't compile for Android... "Well your tool let me do it!"
ReplyDeleteIt's just not that simple. Sometimes it's good to minimize the amount of rope we hand the user with which they try and hang themselves... :)
Allen Bauer the IDE could be smart enought to detect FMX or DFM resources. But with a programmer like me it's not that simple .. I've discovered that Delphi still compiles Kylix's XFM files ;)
ReplyDeletePaul TOTH Again, this seems deceptively simple. What about units used from external libraries which are not listed in the project file? The IDE does look at whether the dpr "uses" Vcl.Forms or Fmx.Forms, so it does kind of try and divine such things. This isn't 100% reliable since people do all kinds of weird and wonderful things that can confuse that logic.
ReplyDeleteAllen Bauer : System.StartupCopy :)
ReplyDeleteIf not that, I am sure you can come up with something else equally unique .
A
Andrea Raimondi did remove it on some project cause I don't know what it is, and the project still works :)
ReplyDeletePaul TOTH you are just evil. :D
ReplyDelete