Le 19 avr. 09 à 18:29, tsuna a écrit :
(catching up on some super old emails)On Wed, Jan 7, 2009 at 8:07 PM, Ralf Wildenhues <[email protected] > wrote:* Peter Rosin wrote on Wed, Jan 07, 2009 at 02:09:38PM CET:Ralf, I have a vague memory of you mentioning that you knew of a project that was using cccl to provide its Windows port, do you remember which project that was? Is anyone else aware of any cccl users?Hmm. Markus Duft started out with cccl IIRC, but quickly switched to implementing his own program. Benoit has made some changes to the script, maybe he knows more (Cc:ed).I used cccl in my previous company, the latest version when I left was at http://tsunanet.net/~tsuna/cccl I don't know if they still use it though. But when I was there we could build all our projects (including Qt-based projects) with the autotools using the MSVC tools (cl.exe and so on). It was very convenient, we could build all our targets (many combinations of compilers / architectures) in just the same way.
FWIW, we are now using the following script, installed as both cl.exe and link.exe. Passing CC=CXX=cl.exe, LD=link.exe, and DUMPBIN='link.exe -dump -symbols'. There does not seem to be a common root between the two scripts, I have no idea why. This script maps Windows file names to Unix path names, so that depcomp can work properly (it also maps -MP and so forth in a way that pleases depcomp). It uses the Perl ndbm module to save calls to winepath, unfortunately this modules does not support concurrent accesses, so this does not work properly with -j :( The way out is certainly to tie the hash to an sqlite database, but this is a TODO.
link.tz2
Description: Binary data
_______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
