There is one last fix I wanted to do before merging but never found the time to do (documented in the PR just now). Mainly because in my perception the effort of maintaining the automated build system is not valued by all developers. So if it gets ignored on a regular basis I don't see a reason to put much effort into maintaining it.
The reason I implemented the automated build system was to prevent the introduction of build breaks into master as a first step of implementing a continuous integration pipeline and more testing. I've written enough about this topic on this mailing list in the last days and I still haven't received any valuable counter arguments to my reasoning there. I'm highly displeased by the way BOINC is currently developed and that there is no constructive discussion about how to fix that. Being part of the working group is my last ditch effort to give BOINC a development process that I think it needs to be sustainable in the future. If that does not work there is no reason for me to continue spending my time on BOINC. I would also like to thank Charlie for his effort and work in testing the travis_osx_build_clean branch and working with me to find a suitable solution. Although we have different styles of developing software, we found a solution that we both can live with in the end. Regards Christian On 31.07.2017 00:45, Charlie Fenton wrote: > Actually this work was finished a long time ago. Christian did most of the > work and I gave feedback and offered some changes to make it easier for me > and any future BOINC Mac developers to do our builds. > > On Mar 24, 2017, at 10:35 PM, Charlie Fenton <charl...@ssl.berkeley.edu> > wrote: >> As far as I am concerned, the travis_osx_build_clean branch is ready to >> merge into master / head in GIT whenever you are ready to do so. Thank you >> for all the good work. > but for some reason Christian never did merge his development branch into GIT > master, though he has the ability to do so. I have already included all the > relevant changes on my end in GIT master. > > @Christian, are you waiting for approval from someone else? > > Cheers, > --Charlie > > On Jul 30, 2017, at 7:39 AM, Vitalii Koshura <lestat.de.lion...@gmail.com> > wrote: > >> Hello all, >> >> In a perfect world such kind of changes are made in a separate branch. >> This helps to avoid broken builds. >> Also we have a pull request https://github.com/BOINC/boinc/pull/1821 which >> also can notify developer about broken build. >> >> @David, could you please take a look at this pull request and at least do >> not commit unfinished work in master (making all changes in a separate >> branch iseven better)? >> >> Thanks >> >> Best regards, >> Vitalii Koshura >> >> 2017-07-30 12:52 GMT+03:00 Richard Haselgrove <r.haselgr...@btopenworld.com> >> : >> >>> I pointed out the Travis build error report almost 12 hours ago, on a >>> mailing list which I know David reads. >>> >>> I don't have your expertise in tracking down the cause of the error (and I >>> don't think I have access to the Travis error messages), but in a case like >>> this, shouldn't the developer temporarily revert the commit, and come back >>> to it later with a fresh pair of eyes to make a second attempt? >>> >>> On Sunday, 30 July 2017, 10:40, Charlie Fenton < >>> charl...@ssl.berkeley.edu> wrote: >>> >>> >>> The latest commit for keyword.cpp and keyword.h broke the builds on the >>> Mac. >>> >>> [1] Adding #include <map> after #include "parse.h" fixes the compiler >>> errors for keyword.h, but I don't know if this needs to be guarded by >>> #ifdef __APPLE__ or if it is OK (and perhaps even necessary) to include it >>> for all platforms, so I have not checked it in. >>> >>> [2] After making that change in keyword.h, I get these compiler errors in >>> keyword.cpp: >>>> ..../lib/keyword.cpp:47:9: error: cannot pass object of non-POD type >>> 'std::string' (aka 'basic_string<char>') through variadic method; call will >>> abort at runtime [-Wnon-pod-varargs] >>>> name, description, parent, level, category >>>> ^ >>>> ..../lib/keyword.cpp:47:15: error: cannot pass object of non-POD type >>> 'std::string' (aka 'basic_string<char>') through variadic method; call will >>> abort at runtime [-Wnon-pod-varargs] >>>> name, description, parent, level, category >>>> ^ >>> According to <https://stackoverflow.com/questions/146452/what-are-pod- >>> types-in-c>: >>>> POD stands for Plain Old Data - that is, a class (whether defined with >>> the keyword struct or the keyword class) without constructors, destructors >>> and virtual members functions. Wikipedia's article on POD goes into a bit >>> more detail and defines it as: >>>> A Plain Old Data Structure in C++ is an aggregate class that contains >>> only PODS as members, has no user-defined destructor, no user-defined copy >>> assignment operator, and no nonstatic members of pointer-to-member type. >>> >>> <https://stackoverflow.com/questions/10440966/c-cannot- >>> pass-objects-of-non-pod-type> explains it this way: >>>> The problem you have is that variable argument functions do not work on >>> non-POD types, including std::string. That is a limiation of the system and >>> cannot be modified. What you can, on the other hand, is change your code to >>> pass a POD type (in particular a pointer to a nul terminated character >>> array): >>> >>> >>> And <https://stackoverflow.com/questions/18319619/c-snprintf- >>> cannot-pass-objects-of-non-pod-type> explains a similar case this way: >>>> snprintf knows nothing about std::string. In this case, it expects >>> null-terminated C strings, that is, pointers to char which are the >>> beginning of a sequence of characters that ends in a null character. You >>> can obtain the underlying null terminated string held by a std::string >>> object via its c_str() method: >>> >>> Cheers, >>> --Charlie >>> >>> _______________________________________________ >>> boinc_dev mailing list >>> boinc_dev@ssl.berkeley.edu >>> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >>> To unsubscribe, visit the above URL and >>> (near bottom of page) enter your email address. >>> >>> >>> >>> _______________________________________________ >>> boinc_dev mailing list >>> boinc_dev@ssl.berkeley.edu >>> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >>> To unsubscribe, visit the above URL and >>> (near bottom of page) enter your email address. >>> >> _______________________________________________ >> boinc_dev mailing list >> boinc_dev@ssl.berkeley.edu >> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >> To unsubscribe, visit the above URL and >> (near bottom of page) enter your email address. >> > _______________________________________________ > boinc_dev mailing list > boinc_dev@ssl.berkeley.edu > https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > To unsubscribe, visit the above URL and > (near bottom of page) enter your email address. _______________________________________________ boinc_dev mailing list boinc_dev@ssl.berkeley.edu https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
