19.06.2011 19:29, Erich Titl пишет: > on 19.06.2011 17:31, Andrew wrote: >> 19.06.2011 17:20, Erich Titl пишет: >>> Hi Andrew >>> >>> on 19.06.2011 16:01, Andrew wrote: >>>> 19.06.2011 16:48, Erich Titl пишет: >>> ... > ... > >> Removing staging/i486-pc-linux-uclibc (and possible i486-* in >> staging/bin) doesn't help for you? > Maybe it would, just that this is not clear at the moment, as buildtool > is fouled up and requires many hours of recompile, hardly what I would > call a seamless operation. > >>> Again, very frustrating. We need an environment which does not have to >>> be rebuilt just because the kernel has changed. >>> >>> - a stable compile environment is mandatory >>> - stable libraries (uClibc) >>> - dependencies must be obeyed, e.g. dependencies of libraries from the >>> kernel >>> >>> Maybe these are all legacy issues, still IMHO not acceptable and maybe >>> this is the reason why we have so little contribution. >> Toolchain and buildtool needs a lot of work - now toolchain is slightly >> modified variant of 3.x branch (just updated and with small patches), >> with a lot of ugly hacks and magic tricks. This will be rewritten - but >> some later, now I haven't enough time (it may require 1-2 weeks). > Maybe there is place for discussion in this area. I would like to see > much of all those perl dirty tricks disappear altogether. > There is standard schema: toolchain (gcc and so on that is running on host CPU) into one directory (toolchain), and all binaries that must be executed on target CPU - into staging dir. There are some examples (as example you can look into script for toolchain compilation for MIPS: http://gitorious.org/wive-rtnl-ralink-rt305x-routers-firmware/wive-rtnl-ralink-rt305x-routers-firmware/blobs/master/toolchain/build_toolchain.sh ). Rewrite toolchain assembly isn't too hard, update buildtool.pl isn't much harder. But I think that all packages should require makefile fixing - thai is main headache. >>> As to GIT, what is the easiest way to avoid conflicting changes in the >>> repository? Creating a local branch of main/master.... whatever? Who >>> does the merge and resolves conflicts? >>> >> Conflicts are resolved better than in CVS - GIT doesn't allow you to >> overwrite file modified by somebody else. > But sometimes this is the goal. > > And merge is automatically >> done if you > Right, but that is not alway what one wants.
>>> How can we, for example, have most packages in the main branch and a few >>> in another, then create objects from both? >> New branch is based on main branch (or other remote/local branch). So if >> there are changes in main branch - you can do rebase for your local >> branch, to import changes into your branch. > So if I just create a branch, what will be contained in that branch and > how is it synchronized to the rest of the tree. How do I just touch a > single component and still get all the updates from others in the game, > while not working in the same branch anymore? The whole concept is > really different from all the other versioning tools I have seen and > that includes SCCS, RCS, CVS and SVC. I am under the impression to have > completely lost control about the versioning tool, instead of gaining > control over the project. When you are on your local branch, just do: git pull; git rebase main > How is the integration of git into make? Can we automatically get a file > out of GIT to resolve a 'make dependency' or is this not needed at all? > A bit off topic, I know, but there are just holes in my conception, but > then I never saw any of such errors in the ancient versioning control > systems as I have seen in the last few weeks. > > cheers > > Erich > There is no integration. Git is separate, make (and buildtool that fetches files from anywhere if you specified - including CVS/GIT/etc trees) is separate. Now files are 'fetched' (using symlinks) from 'repo' directory. You may 'fetch' them from other place (be copying, symlink or something else). Also there is 'sources.local' file for specifying sources that aren't into main branch (I planning to exclude it out from git and make auto-generation of blank file if there is no file by buildtool.pl). ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
