Mark Rages schrieb: > The Makefile in packaging seems to think it's a shell script. Quoting: > >> # Build and install step by step. >> # >> # e.g. to build gcc, it is required to have a working msp430 binutils this >> # is ensured by first building and installing them, then building and >> # installing gcc and so on. >> # >> # On Windows, stripfiles must be called before the python tools are installed >> # or they will be broken. >> build: binutils-build binutils-install \ >> gcc-build gcc-install \ >> msp430-libc-build msp430-libc-install \ >> gdb-build gdb-install \ >> libmspgcc-build libmspgcc-install \ >> stripfiles \ >> pytools-build pytools-install \ >> libraries-build libraries-install > > make has a facility called "dependencies" to make sure that builds are > executed in the proper order.
and this is also used in the makefile > For example, the gcc-build target could specify binutils-install as a > dependency so that Make would build it first. you'd need to write marker files to remember that binutils is installed for example as the install targets doesn't write a file of the name of the rule on its own. > The shell-script approach is a failure for several reasons. maybe, but please realize that the windows installer needs to be built and it needs a list of installed files. therefore it needs to track what each step installs. as everything is installed in one target folder it's not possible to know which file is coming from which install unless it's done one after the other using the file list tracking. i once tried to install binutils, gcc, gdb to separate folders so that packaging would get much easier. but gcc made assumptions about the path of binutils tools, failing to build. so i gave up on that. > One reason is that make -j will not be able to parallelize properly > without understanding the actual dependency graph. i don't care about that. gcc uses binutils no possibility to sequence that and that's the bigger part of the build time. experiments with parallelizing, possibly getting more errors is not worth the time to try it out :/ that said, my last attempt to build it on windows took 183 minutes until it failed with an error about cygwin getting no more memory (while it's using msys/mingw32 for the build...). i don't understand why on windows, each time i try to compile it, it gets slower and slower. 2001 it was able to compile binutils and gcc in 20 minutes on a 600MHz machine. last time it took 90 minutes on 2GHz, now 180 minutes and fails. that said.. someone reading this, running windows, and being an optimist... it would be good if someone else could try to build the windows installer. README-MAINTAINER.txt in packaging should contain the instructions. when something is missing, ask and we will make that readme better. > Another reason, one that's bothering me right now, is that when a > build bombs out, I cannot go edit the file that's causing the problem, > and restart the build. It will start building over from the > beginning, which takes a long time. yes, i inserted the cleans before the build intentionally. because when i'm doing a windows installer i do not want incremental builds with manual edits. if you care and want to improve the makefile, you're welcome. just keep i mind that it must be able to build the windows installer and install to /opt under linux. if you even manage to cross compile the tools from linux, that would be great. but i thing the gcc 3.2.3 configuration doesn't mange that. (when the libraries need to be compiled it calls the cross compiler of the host system instead of build system, failing to execute the windows binary on linux..) chris > Regards, > Mark > markra...@gmail
