From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14969 invoked by alias); 10 Sep 2014 19:37:29 -0000 Mailing-List: contact gcc-cvs-wwwdocs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-cvs-wwwdocs-owner@gcc.gnu.org Received: (qmail 14944 invoked by uid 9067); 10 Sep 2014 19:37:29 -0000 Message-ID: <20140910193729.14942.qmail@sourceware.org> From: hp@gcc.gnu.org Date: Wed, 10 Sep 2014 19:37:00 -0000 To: gcc-cvs-wwwdocs@gcc.gnu.org Subject: wwwdocs/htdocs simtest-howto.html User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2014/txt/msg00304.txt.bz2 Files modified in the GCC repository. Log entry: Clarifications and updated check-out instructions mainly for repo changes. First, as noted, the instructions are outdated due to repos merging, splitting, moving and switching, with fallout such as it now seemed odd as-is with one minor component randomly being named "src". (It's a CVS artefact: when the "-d topdir" option is used, cvs-1.11.22 gets confused over the "newlib" subdirectory different to the "newlib" CVS module; add -N and you get the "src" subdirectory anyway, within "topdir". Love CVS! If someone has a simple working solution just using options and it works for me too, we can call the newlib topdir something else than "src". In the meantime, not going there.) There was other outdated information, such as gcc-2.95 being a valid host-gcc. Hah! Better point to the general build prerequisites. Also, the idea of using a *combined* tree here, has been challenged, so I toned down the wording from the actual "require" to the negation(!) and added an apologetic blurb. (For my own autotester, I use a separate install as mentioned in the blurb, if only to simplify not depending on a simultaneous working state, but I wouldn't do a separate build just for newlib, so some kind of combination instructions seems called for anyway.) There has also historically been people doing their edits in the combined tree. (Understandable; that's where gdb points...) Better add a few words about that. With the combined binutils-gdb.git used as-is, now GDB has to be manually disabled so we don't have to worry about its target obsoletion triggers. The gdb we're likely to use it probably the host gdb anyway. (If it's recent enough that is; if not, it might be a good idea to install a native build somewhere locally, to apply on the cross-gcc.) Also arm-elf is obsoleted, so let's choose arm-eabi for the example. Except when trying that, thebuild gets lost building libjava. Rather than choosing a target which mostly by coincidence doesn't enable java (lack of libffi), I just added a language option to make it more likely for a random build for a random target to complete. ISTR reports to the gcc-testresults@ for several targets but just for c and c++ enabled. If you think this is a bad move, I'd value work fixing the situation in the right way (see above) higher than just an opinion. Also, the reason is explained and people are free to not use --enable-languages when testing. I see mcore-elf build; I could use that instead but let's not go to far off main-stream. I could use cris-elf if I also wanted decent test-results, but I'm probably too biased to offer that with a straight face. ;) As a future step, we may want to just drop the status-ish table at the end, for one it's out of date by a decade.