>>> 10) Support BUILD-EVENTS that when the hbIDE for start and end the >>> process build it call some specific user-commands (such as calling the >>> upx, send the generated file via FTP or run any other program like >>> compression or encryption, etc.) >> >> I missed that one. Well, hbmk2 _does_ copying to any filesystem >> target after successful build (-instpath= option), it also supports >> upx for compression (-compr option), which leaves FTP/SCP and >> friends, and to address that shortly: I wouldn't like to convert >> hbmk2 into a 'curl' clone, it simple hasn't got any point to >> duplicate existing functionality in an inferior fashion. >> >> BTW, you missed installer creation which is also a feature missing >> from hbmk2, and it will probably be missing forever due to >> the many variations and due to the fact that building installers >> is rarely tied 1 to 1 to building binaries, so some 'postbuild' >> script seems to fit the task better. For sure newer IDEs offer >> such feature, but I don't know how usable it is at this stage. >> >> There is also .app bundle creation on OS X, which hbmk2 tries >> to do now, but it's pretty much experimental yet. >> >> Overall there can be any number and sort of prebuild/postbuild >> tasks that users may want to automate, but as a general rule >> I'd like to keep hbmk2 as the builder tool only. Though if >> there is some generic and portable task that seems to be better >> suited for hbmk2, we can still add it there. > > Ok, I understand that Viktor ... but I speak not to change the hbmk2 > to insert it these resources, because hbmk2 did not need this. I speak > from hbIDE give me a field for me to customize these actions on my > project. So I can work on my CPU in "Debug Mode" and when I finished, > I compile in "Release mode" and her call my batch file that compress > my app with custom software (not UPX) and send it via FTP or do other > things that I consider important.
Clear to me. I wrote these to draw the line where hbmk2 ends and HBIDE starts. In some cases it may not be obvious first. We should implement everything in its best place and avoid implementing the same thing in both projects, as a general rule. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
