Re: [RFC] squid-3.6 unit tests
On 24/08/2014 12:01 p.m., Amos Jeffries wrote: On 24/08/2014 3:59 a.m., Alex Rousskov wrote: If the proposed changes take a few months to implement, then yes, I agree, we should not wait. If it is a matter of a week or two, I suggest doing it now. This is your call though. It should be a relatively quick job. I will give it a shot while waiting on boilerplate. Spoke too soon. We will have to sort out the automake subdir-objects issues first. Amos
Re: [RFC] squid-3.6 unit tests
On 23/08/2014 5:41 a.m., Alex Rousskov wrote: On 08/20/2014 09:16 PM, Amos Jeffries wrote: Future versions of autoconf/automake will be auto-enabling their subdir-objects feature. This impacts Squid in a few ways, the largest being how we perform unit testing. At present our unit tests link to objects in $(top_srcdir)/src/tests/ and sometimes from other src/foo/ directories. The current automake will build a .o file in the current working directory, but with subdir-objects the .o would be built in the src/tests/ etc directory and shared between any other units using the base .c file. This will naturally cause build failures when the source sub-directory has not yet been created by the build process. subdir-objects is not automatically creating paths. I am proposing that: 1) we reverse the decision to build any unit tests in src/ subdirectories. Returning to the original design of using top level test-suite/ directory to build and run them. This will ensure that all necessary .la objects and src/ directories are already existing before unit tests get built. We are already facing some problems from that plan. For example when unit tests for src/fs/ need to link against src/http/*.la we currently have to build them in src/Makefile.am after all src/*/ sub-directories have been recursed and built. Some possible compat/ unit tests are also blocked by lib/* not being built at the time. 2) the STUB .cc files are moved from src/tests/. With subdir-objects we can a) place them in the relevant src/foo/ directory, or b) place them in src/stubs/. With a rename from stub_foo.cc to foo.stub.cc so we can make use of a generic automate their build and dist operations from Common.am (in case of 2a) or src/stubs/Makefile.am (in case of 2b). No objections from me. While it would be better to localize unit tests, our unit tests are apparently not local enough to be easily localized. In many cases, this is probably due to poor quality of the primary code (too many dependencies), and will take a while to improve. If agreed this would take effect after 3.5 branching. This is your call, but I am surprised you want to make such a relatively big (and yet essentially simple) change after branching. I would recommend to do it before you branch to minimize long-term maintenance overheads. Changes big enough to affect the unit tests operations or results are (small?) feature or interface updates which are not really candidates for backporting under the current release policy. So the difference between branches caused by this should not matter for porting bug fixes around in the main code. Amos
Re: [RFC] squid-3.6 unit tests
On 08/23/2014 04:20 AM, Amos Jeffries wrote: On 23/08/2014 5:41 a.m., Alex Rousskov wrote: On 08/20/2014 09:16 PM, Amos Jeffries wrote: Future versions of autoconf/automake will be auto-enabling their subdir-objects feature. This impacts Squid in a few ways, the largest being how we perform unit testing. At present our unit tests link to objects in $(top_srcdir)/src/tests/ and sometimes from other src/foo/ directories. The current automake will build a .o file in the current working directory, but with subdir-objects the .o would be built in the src/tests/ etc directory and shared between any other units using the base .c file. This will naturally cause build failures when the source sub-directory has not yet been created by the build process. subdir-objects is not automatically creating paths. I am proposing that: 1) we reverse the decision to build any unit tests in src/ subdirectories. Returning to the original design of using top level test-suite/ directory to build and run them. This will ensure that all necessary .la objects and src/ directories are already existing before unit tests get built. We are already facing some problems from that plan. For example when unit tests for src/fs/ need to link against src/http/*.la we currently have to build them in src/Makefile.am after all src/*/ sub-directories have been recursed and built. Some possible compat/ unit tests are also blocked by lib/* not being built at the time. 2) the STUB .cc files are moved from src/tests/. With subdir-objects we can a) place them in the relevant src/foo/ directory, or b) place them in src/stubs/. With a rename from stub_foo.cc to foo.stub.cc so we can make use of a generic automate their build and dist operations from Common.am (in case of 2a) or src/stubs/Makefile.am (in case of 2b). No objections from me. While it would be better to localize unit tests, our unit tests are apparently not local enough to be easily localized. In many cases, this is probably due to poor quality of the primary code (too many dependencies), and will take a while to improve. If agreed this would take effect after 3.5 branching. This is your call, but I am surprised you want to make such a relatively big (and yet essentially simple) change after branching. I would recommend to do it before you branch to minimize long-term maintenance overheads. Changes big enough to affect the unit tests operations or results are (small?) feature or interface updates which are not really candidates for backporting under the current release policy. So the difference between branches caused by this should not matter for porting bug fixes around in the main code. The amount of porting work is determined primarily by the difference between branches, not policy that classifies those differences. Any difference or exception usually means more porting work. Thus, I am surprised you prefer to increase that difference between future trunk and future v3.5 branch in this particular case. If the proposed changes take a few months to implement, then yes, I agree, we should not wait. If it is a matter of a week or two, I suggest doing it now. This is your call though. Cheers, Alex.
Re: [RFC] squid-3.6 unit tests
On 24/08/2014 3:59 a.m., Alex Rousskov wrote: If the proposed changes take a few months to implement, then yes, I agree, we should not wait. If it is a matter of a week or two, I suggest doing it now. This is your call though. It should be a relatively quick job. I will give it a shot while waiting on boilerplate. Amos
Re: [RFC] squid-3.6 unit tests
On 08/20/2014 09:16 PM, Amos Jeffries wrote: Future versions of autoconf/automake will be auto-enabling their subdir-objects feature. This impacts Squid in a few ways, the largest being how we perform unit testing. At present our unit tests link to objects in $(top_srcdir)/src/tests/ and sometimes from other src/foo/ directories. The current automake will build a .o file in the current working directory, but with subdir-objects the .o would be built in the src/tests/ etc directory and shared between any other units using the base .c file. This will naturally cause build failures when the source sub-directory has not yet been created by the build process. subdir-objects is not automatically creating paths. I am proposing that: 1) we reverse the decision to build any unit tests in src/ subdirectories. Returning to the original design of using top level test-suite/ directory to build and run them. This will ensure that all necessary .la objects and src/ directories are already existing before unit tests get built. We are already facing some problems from that plan. For example when unit tests for src/fs/ need to link against src/http/*.la we currently have to build them in src/Makefile.am after all src/*/ sub-directories have been recursed and built. Some possible compat/ unit tests are also blocked by lib/* not being built at the time. 2) the STUB .cc files are moved from src/tests/. With subdir-objects we can a) place them in the relevant src/foo/ directory, or b) place them in src/stubs/. With a rename from stub_foo.cc to foo.stub.cc so we can make use of a generic automate their build and dist operations from Common.am (in case of 2a) or src/stubs/Makefile.am (in case of 2b). No objections from me. While it would be better to localize unit tests, our unit tests are apparently not local enough to be easily localized. In many cases, this is probably due to poor quality of the primary code (too many dependencies), and will take a while to improve. If agreed this would take effect after 3.5 branching. This is your call, but I am surprised you want to make such a relatively big (and yet essentially simple) change after branching. I would recommend to do it before you branch to minimize long-term maintenance overheads. Thank you, Alex.
