Op 15 jun. 2011 17:51 schreef "Jon" <[email protected]> het volgende:
>
> > After messing around with winpthreads and posix-enabled gcc which
> > doesn't work well yet (so no std::thread yet), I have steamed up
> > another revisionary release of my 4.6.1 prerelease builds.
> >
> > This time, I bring:
> >
> > - python-enabled gdb (yeah, I know, not new, but I'm still proud of it)
> > - fixed exception catching which was apparently broken in my 4.6.1-2
> > - Linux builds! One minor caveat: they are x86_64 hosted, so you'll
> > need 64-bit linux, but that shouldn't be a problem these days I think.
> > - As usual, everything is optimized for core2 with Graphite
optimizations.
> > - Languages: C(++),Fortran,Obj-C(++)
> >
> > I've considered ada support, but if nobody asks, I won't include it,
> > the package is fat enough already.
> >
> > Re the splitting in parts: a good idea, if there were some installer
> > or automated way of getting these packages. I know there's mingw-get,
> > but I haven't looked at that yet. Instead, I've manually repackaged
> > the windows binaries in a Awesomely-compressed LZMA2 7z-compressed
> > 30MB package, but you'll need 7zip to open it of course. Unpacked it
> > is less than 300MB.
>
> Nice and fantastic to see the 7z windows binaries!
>
> Re splitting, your toolchain/scripts/zipping.sh could be supercharged to
automate things into a base package (C/C++) and separate overlay packages
for Fortran and Obj-C. But then you've got the SF
bundle-o-packages-for-each-release maintenance issue.
Not really a maintenance issue really, only an upload issue. I've already
decided to make subdirectories to keep the "find the right toolchain" as
straightforward as possible, now that there's going to be at least two files
per release.
>
> Given the packages are relatively small, I'm wondering if embeddeding a
script (.sh or .py) that one manually runs after download/extract that
simply walks the dir tree deleting artifacts wouldn't be a more manageable
way to go. Start small and have the script just delete Fortran and Obj-C
artifacts and leave the base C/C++ artifacts. If people want it to do more,
they can send you pull requests on your git repo. Are the dependencies such
that one can simply delete artifacts and the base C/C++ and GDB still works?
There's special targets when you build gcc, I just haven't found them (or
looked for them, it's not like there's a well documented list ;-) ). getting
rid of the additions would be worse, and very dependent on the internals of
GCC's directory layout.
I think this scheme provides maximal splitting:
- core: gcc+libgcc+binutils+(+pthreads, of course)+mingw-w64 crt
- C++: g++ and libstdc++
- Obj-C(++) and runtime libs
- Fortran and runtime lib
- (ada + runtime libs)
- (go + runtime libs)
- (any other language nobody seems to need)
- gdb+python files
And I could install all these into their prefix seperately, zip, and rename
the prefix directory. I've thought it out, and it should work, except that
the general install step in each script will be more involved. This is
pretty much how a general Linux distro does it, nothing fancy about it, just
have to take my time to make the modifications to the scripts ;-).
Cheers,
Ruben
------------------------------------------------------------------------------
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
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
