<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br></span>I'm now calling it out as a design problem in<br>
CMake, especially as the winds have shifted to more platforms focusing<br>
on shipping binaries than the former and now treat packaging as a<br>
first class citizen. It is an impediment to the natural workflow on<br>
those platforms, it is an impediment to people adopting CMake, and it<br>
is an impediment to people wanting to deal with native languages<br>
because build systems are too complicated. </blockquote><div><br></div><div>Using cmake requires adaptation of workflow.  That in itself is already an added complication for VS etc sort of developers that want to just use the high level IDE functions to, say, add a source file...if you don't want to 'impede natural workflow' don't use cmake?</div><div><br></div><div>It was an impediment to me when first started, because the makefile system I was coming from I already had targets going to the right locations... had to adapt thinking to allow cmake to track its build products separately and then add an install rule to gather them together.... but doing that once I did I have no regrets.  </div><div><br></div><div>I don't develop for Mac; so don't know issues with signing there.... but then I've not seen a lot of complaints come across the list like 'sure would wish that...'</div><div><br></div><div>even if you're just shipping binaries likely you also have additional resources needed to be included.... and that the binary will be an installable package.  Can still just zip the temp install location and distribute that... </div><div><br></div><div><span class=""><br></span>"I don't think this is true at all. My scripts do the "right" thing<br>when you build and they are efficient.  But I still respect INSTALL<br>and you can still install. I still use INSTALL and PACKAGE,<br>particularly the latter on Windows for creating an NSIS installer."<br><div class=""></div></div><div><br></div><div>I used some macros to make implementation simpler so I can just do "install_default( target_name)" and even that I don't really like, because it's not 'native' so I found people had issues dealing with it, even if it was just a matter of copy and paste and change a name... adding addtional scripts with their own esoterics I don't think is a good thing either... </div><div><br></div><div>True; in the beginning, I thought I wanted lists of libraries etc that were used to build an exectuable so I could just reference that and all dependant files... but in reality I didn't really need that once they were just all put in the same location.  My old make system used to do a 'program_copy' command which would read a target list of .exe and .dll  (or .so on linux) and do a copy of all files that were actually referenced... this failed for plugins though, since they are dynamically referenced through code.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">
<br>
Thanks,<br>
Eric<br>
--<br>
Beginning iPhone Games Development<br>
<a href="http://playcontrol.net/iphonegamebook/" target="_blank">http://playcontrol.net/iphonegamebook/</a><br>
</div></div></blockquote></div><br></div></div>