From: Ben S. <pow...@16...> - 2014-07-11 07:43:20
|
Hi, I am setting up an ARMv7 build machine. I find that the others in the build farm only do regression test on 8-9 ports. For example, http://sdcc.sourceforge.net/regression_test_results/amd64-unknown-linux2.5/regression-test-amd64-unknown-linux2.5-20140710-9043.log That hc08, pic, z80, tlcs90 are not tested. Why ? Ben |
From: Erik P. <epe...@iv...> - 2014-07-11 08:05:10
|
On Fri, 11 Jul 2014, Ben Shi wrote: > Hi, > > I am setting up an ARMv7 build machine. I find that the others in the build > farm only do regression test on 8-9 ports. > > For example, > http://sdcc.sourceforge.net/regression_test_results/amd64-unknown-linux2.5/ > regression-test-amd64-unknown-linux2.5-20140710-9043.log > > That hc08, pic, z80, tlcs90 are not tested. > > Why ? > > Ben I think you must have missed my previous reply on this topic that mostly answers this question. See the archive copy here: http://sourceforge.net/p/sdcc/mailman/message/32484189/ I don't have an answer for tlcs90. I suppose it could be added if Philipp thinks it's ready. Erik |
From: Philipp K. K. <pk...@sp...> - 2014-07-11 08:35:57
|
Am 11.07.2014 10:04, schrieb Erik Petrich: > > I don't have an answer for tlcs90. I suppose it could be added if Philipp > thinks it's ready. While the port itself is ready, the simulator is not: ucsim doesn not support tlcs90. There is another simulator for tlcs90 around (and the author agreed to relicense it under a free license), but AFAIR both me and Rainer have been busy with other things, so it never made its way to sdcc. Philipp |
From: Philipp K. K. <pk...@sp...> - 2014-07-11 08:16:29
|
Am 11.07.2014 09:43, schrieb Ben Shi: > Hi, > > I am setting up an ARMv7 build machine. I find that the others in the > build farm only do regression test on 8-9 ports. > > For example, > http://sdcc.sourceforge.net/regression_test_results/amd64-unknown-linux2.5/regression-test-amd64-unknown-linux2.5-20140710-9043.log > > That hc08, pic, z80, tlcs90 are not tested. > > Why ? > > Ben They alternate between different ports. Since e.g. the z80 port is similar to the z180 port, we test z80 one day and z180 the other. This helps slower machines, which otherwise wouldn't be able to run the tests. Also the pic14 port is so broken, there's no point in testing. The pic16 port should be ready for testing by now, but historically wasn't. Philipp |
From: Ben S. <pow...@16...> - 2014-07-14 06:53:47
|
Erik, Thanks for your help. I am trying to make my arm board become a build farm member, by following section "How to become a Distributed Compile Farm member (builder)" @ http://sdcc.sourceforge.net/mediawiki/index.php/Distributed_Compile_Farm . If I choose the sdcc-build/lib/variables.mk you mentioned previously, does it means that 1. The avr, ds400, pic14, pic16 and tlcs90 ports are not built. 2. Before I apply an account from you, I need a internal full test on my board with 2.1 configure --disable the above 5 ports 2.2 make all 2.3 make install 2.4 make test Right? Ben 在2014年07月11 16时04分,"Erik Petrich"<epe...@iv...>写道: On Fri, 11 Jul 2014, Ben Shi wrote: > Hi, > > I am setting up an ARMv7 build machine. I find that the others in the build > farm only do regression test on 8-9 ports. > > For example, > http://sdcc.sourceforge.net/regression_test_results/amd64-unknown-linux2.5/ > regression-test-amd64-unknown-linux2.5-20140710-9043.log > > That hc08, pic, z80, tlcs90 are not tested. > > Why ? > > Ben I think you must have missed my previous reply on this topic that mostly answers this question. See the archive copy here: http://sourceforge.net/p/sdcc/mailman/message/32484189/ I don't have an answer for tlcs90. I suppose it could be added if Philipp thinks it's ready. Erik ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ sdcc-devel mailing list sdc...@li... https://lists.sourceforge.net/lists/listinfo/sdcc-devel |
From: Erik P. <epe...@iv...> - 2014-07-15 03:38:41
|
On Mon, 14 Jul 2014, Ben Shi wrote: > Erik, > > Thanks for your help. > > I am trying to make my arm board become a build farm member, by following > section "How to become a Distributed Compile Farm member (builder)" @ > http://sdcc.sourceforge.net/mediawiki/index.php/Distributed_Compile_Farm . > > If I choose the sdcc-build/lib/variables.mk you mentioned previously, does > it means that > > 1. The avr, ds400, pic14, pic16 and tlcs90 ports are not built. You don't choose sdcc-build/lib/variables.mk. It it used automatically by the build scripts/makefiles. Of the ports that you mention (avr, ds400, pic14, pic16, and tlcs90) only avr is not built. The others are built, but do not run the regression tests. The pic14 and pic16 ports need the current version of gputils installed so that their standard libraries can be built. The variables.mk file controls which regression tests are run on which days. > 2. Before I apply an account from you, I need a internal full test on my > board with > 2.1 configure --disable the above 5 ports > 2.2 make all > 2.3 make install > 2.4 make test > > Right? Kind of. If gputils is installed properly, you should be able to use configure without any --disable options. It's also not necessary to install before running the regression tests (they will automatically use a relative path to find the locally built executables and libraries). So it's basically: 2.1 configure 2.2 cd support/regression 2.3 make If this works, then you'll want to try using the DCF scripts. Follow the instructions on this page of the wiki: http://sdcc.sourceforge.net/mediawiki/index.php/HOWTO_Make_Snapshot_Builds_on_the_Developer_Machine The final command there ~/build/sdcc-build-bootstrap.sh crontab-spawn 2>&1 | tee ~/build/log.txt will do everything that's part of the daily snapshots, with the exception of uploading the final snapshot and regression results to the DCF mediator server. Erik |
From: Ben S. <pow...@16...> - 2014-07-16 03:41:44
|
Erik, Thanks. I have passed full regression tests of most ports (without pic, avr, and tlcs90) on my arm board. Now the sdcc-build-bootstrap.sh is running, and I will check if it can run continuously run for days, as a stability test of my board. If everything can be OK, I will ask you for an account. Ben 在2014年07月15 11时38分,"Erik Petrich"<epe...@iv...>写道: On Mon, 14 Jul 2014, Ben Shi wrote: > Erik, > > Thanks for your help. > > I am trying to make my arm board become a build farm member, by following > section "How to become a Distributed Compile Farm member (builder)" @ > http://sdcc.sourceforge.net/mediawiki/index.php/Distributed_Compile_Farm . > > If I choose the sdcc-build/lib/variables.mk you mentioned previously, does > it means that > > 1. The avr, ds400, pic14, pic16 and tlcs90 ports are not built. You don't choose sdcc-build/lib/variables.mk. It it used automatically by the build scripts/makefiles. Of the ports that you mention (avr, ds400, pic14, pic16, and tlcs90) only avr is not built. The others are built, but do not run the regression tests. The pic14 and pic16 ports need the current version of gputils installed so that their standard libraries can be built. The variables.mk file controls which regression tests are run on which days. > 2. Before I apply an account from you, I need a internal full test on my > board with > 2.1 configure --disable the above 5 ports > 2.2 make all > 2.3 make install > 2.4 make test > > Right? Kind of. If gputils is installed properly, you should be able to use configure without any --disable options. It's also not necessary to install before running the regression tests (they will automatically use a relative path to find the locally built executables and libraries). So it's basically: 2.1 configure 2.2 cd support/regression 2.3 make If this works, then you'll want to try using the DCF scripts. Follow the instructions on this page of the wiki: http://sdcc.sourceforge.net/mediawiki/index.php/HOWTO_Make_Snapshot_Builds_on_the_Developer_Machine The final command there ~/build/sdcc-build-bootstrap.sh crontab-spawn 2>&1 | tee ~/build/log.txt will do everything that's part of the daily snapshots, with the exception of uploading the final snapshot and regression results to the DCF mediator server. |
From: Ben S. <pow...@16...> - 2014-07-17 03:15:38
|
For making snapshot build, what is the difference between"by hand" and "by srcipt" ? I succeeded to do the regression test "by hand", but failed "by script". 在2014年07月15 11时38分,"Erik Petrich"<epe...@iv...>写道: On Mon, 14 Jul 2014, Ben Shi wrote: > Erik, > > Thanks for your help. > > I am trying to make my arm board become a build farm member, by following > section "How to become a Distributed Compile Farm member (builder)" @ > http://sdcc.sourceforge.net/mediawiki/index.php/Distributed_Compile_Farm . > > If I choose the sdcc-build/lib/variables.mk you mentioned previously, does > it means that > > 1. The avr, ds400, pic14, pic16 and tlcs90 ports are not built. You don't choose sdcc-build/lib/variables.mk. It it used automatically by the build scripts/makefiles. Of the ports that you mention (avr, ds400, pic14, pic16, and tlcs90) only avr is not built. The others are built, but do not run the regression tests. The pic14 and pic16 ports need the current version of gputils installed so that their standard libraries can be built. The variables.mk file controls which regression tests are run on which days. > 2. Before I apply an account from you, I need a internal full test on my > board with > 2.1 configure --disable the above 5 ports > 2.2 make all > 2.3 make install > 2.4 make test > > Right? Kind of. If gputils is installed properly, you should be able to use configure without any --disable options. It's also not necessary to install before running the regression tests (they will automatically use a relative path to find the locally built executables and libraries). So it's basically: 2.1 configure 2.2 cd support/regression 2.3 make If this works, then you'll want to try using the DCF scripts. Follow the instructions on this page of the wiki: http://sdcc.sourceforge.net/mediawiki/index.php/HOWTO_Make_Snapshot_Builds_on_the_Developer_Machine The final command there ~/build/sdcc-build-bootstrap.sh crontab-spawn 2>&1 | tee ~/build/log.txt will do everything that's part of the daily snapshots, with the exception of uploading the final snapshot and regression results to the DCF mediator server. |
From: Erik P. <epe...@iv...> - 2014-07-17 07:46:22
|
On Thu, 17 Jul 2014, Ben Shi wrote: > For making snapshot build, what is the difference between"by hand" and "by > srcipt" ? > > I succeeded to do the regression test "by hand", but failed "by script". Ultimately, it needs to run entirely by the script alone. However, if you've never compiled sdcc on a particular platform before, I think the "by hand" process provides more opportunity to notice errors (usually missing tools or libraries) and correct them. It also tests more ports than the script during one session (you would need to run the script on two consecutive days to get the same coverage). Erik |
From: Ben S. <pow...@16...> - 2014-07-17 05:30:54
|
Is test-host necessary for a build machine? Can we switch off it? 在2014年07月17 11时15分,"pow...@16..."<pow...@16...>写道: For making snapshot build, what is the difference between"by hand" and "by srcipt" ? I succeeded to do the regression test "by hand", but failed "by script". 在2014年07月15 11时38分,"Erik Petrich"<epe...@iv...>写道: On Mon, 14 Jul 2014, Ben Shi wrote: > Erik, > > Thanks for your help. > > I am trying to make my arm board become a build farm member, by following > section "How to become a Distributed Compile Farm member (builder)" @ > http://sdcc.sourceforge.net/mediawiki/index.php/Distributed_Compile_Farm . > > If I choose the sdcc-build/lib/variables.mk you mentioned previously, does > it means that > > 1. The avr, ds400, pic14, pic16 and tlcs90 ports are not built. You don't choose sdcc-build/lib/variables.mk. It it used automatically by the build scripts/makefiles. Of the ports that you mention (avr, ds400, pic14, pic16, and tlcs90) only avr is not built. The others are built, but do not run the regression tests. The pic14 and pic16 ports need the current version of gputils installed so that their standard libraries can be built. The variables.mk file controls which regression tests are run on which days. > 2. Before I apply an account from you, I need a internal full test on my > board with > 2.1 configure --disable the above 5 ports > 2.2 make all > 2.3 make install > 2.4 make test > > Right? Kind of. If gputils is installed properly, you should be able to use configure without any --disable options. It's also not necessary to install before running the regression tests (they will automatically use a relative path to find the locally built executables and libraries). So it's basically: 2.1 configure 2.2 cd support/regression 2.3 make If this works, then you'll want to try using the DCF scripts. Follow the instructions on this page of the wiki: http://sdcc.sourceforge.net/mediawiki/index.php/HOWTO_Make_Snapshot_Builds_on_the_Developer_Machine The final command there ~/build/sdcc-build-bootstrap.sh crontab-spawn 2>&1 | tee ~/build/log.txt will do everything that's part of the daily snapshots, with the exception of uploading the final snapshot and regression results to the DCF mediator server. |
From: Erik P. <epe...@iv...> - 2014-07-17 07:58:56
|
On Thu, 17 Jul 2014, Ben Shi wrote: > Is test-host necessary for a build machine? > > Can we switch off it? I think it's a good idea to include it as part of the test. It allows us to verify that the test itself is both valid and unambiguous C. As you have found with the regression test involving the inline keyword, there are places that the C standard allows the compiler to be implemented in more than one way. If the regression test assumes only one of those ways, then the test itself is faulty. We want tests that pass if the compiler is working correctly, regardless of its implementation. Erik |