From: Amitha P. <pe...@cs...> - 2004-08-11 14:39:30
|
Folks, I think we all need to be more active in ensuring that the builds dashboard is useful. Every so often, something goes wrong and there are broken build emails sent that are not caused by a code change. The cause may be the dashboard scripts failing, or by one of the submitting build configurations going bad, or some other cause. It is important that we fix these as soon as it is noticed. This implies that whoever notices it should alert someone. One central point of contact is this list. If you did not commit anything the day before, you should not receive an email about a broken build. If you do, something is wrong. Alert the list! If you did commit something and receive and email, look at the error message. If the error is unrelated to your change, and someone else has also committed something that may have caused the problem, ignore it. Otherwise, if the error is something that you cannot correct, do not understand, or need help correcting, alert the list! Any comments on the whole dashboard, the broken build emails, and so on? We should continue to keep VXL multi-platform and multi-compiler, but should strive to make the process as unobtrusive as possible. Amitha. |
From: Peter V. <Pet...@es...> - 2004-09-01 16:23:54
Attachments:
VCL_INSTANTIATION_FILES
|
Did I understand correctly that all files */Templates/vcl_* can be safely removed? Don't we have (or support) anymore any compilers that need those explicit instantiations of STL templates? Or maybe they should only be compiled when VCL_USE_NATIVE_STL is not on, i.e., when using vcl/emulation ? Attached is a full list of all those files; maybe someone could try removing these and see if e.g. old versions of gcc or VC++ or SunPro get into trouble. (Note that complex<T> instantiations are NOT in this list.) -- Peter. |
From: Amitha P. <pe...@cs...> - 2004-09-01 16:39:58
|
On Wed 01 Sep 2004, Peter Vanroose wrote: > Did I understand correctly that all files */Templates/vcl_* can be > safely removed? I think they can safely be removed. In fact, I committed a change that commented out the AUX_TEMPLATES_DIR in the vcl/CMakeLists.txt file about a week ago, and all CMake-based builds are happy. > Don't we have (or support) anymore any compilers that need those > explicit instantiations of STL templates? We used the explicit vcl instantiations when we were forcing explicit template instantiation through-out the VXL tree. With the standard library more widely supported, we shouldn't be doing that. Fred S. implemented a change long ago that made vcl implicitly instantiated. This has been the default for a long time, and hasn't caused problems. Even the STL in emulation shouldn't require explicit instantiation. Most, if not all, standard library implementations are designed to work with implicit instantiation. To me, implicit instantiation with the standard library always worked. What got us into trouble was trying to explicitly instantiate stuff in there. So, I don't think there will be any problems with older compilers. Not related to insantiation, anyway. Conformance issues will always be there, but that's what vcl as a whole deals with. Everything I've said above applies to the template instantiations in vcl itself. Does something like vcl_set<bgrl_edge_sptr> need to be explicitly instantiated? My feeling is that is does not. Presumably the appropriate file, vcl_set+bgrl_edge_sptr+.cxx, only includes vcl_set.txx and bgrl_edge_sptr.h and *does not* include bgrl_edge_sptr.txx. I'm going to be away 'till the middle of next week. If no-one tries is before than, I'll remove these files then and see what happens on the dashboard. Amitha. |
From: Peter V. <Pet...@es...> - 2004-09-01 17:05:02
|
> Everything I've said above applies to the template instantiations in > vcl itself. Does something like vcl_set<bgrl_edge_sptr> need to be > explicitly instantiated? My feeling is that is does not. I've indeed removed those instantiations locally, and gcc 3.3 does not have any problems, and neither does SGI's native compiler. -- Peter. |