swig / cccl Goto Github PK
View Code? Open in Web Editor NEWUnix cc compiler to Microsoft's cl compiler wrapper
License: GNU General Public License v3.0
Unix cc compiler to Microsoft's cl compiler wrapper
License: GNU General Public License v3.0
SWIG (Simplified Wrapper and Interface Generator) Tagline: SWIG is a compiler that integrates C and C++ with languages including Perl, Python, Tcl, Ruby, PHP, Java, C#, D, Go, Lua, Octave, R, Scheme (Guile, MzScheme/Racket), Scilab, Ocaml. SWIG can also export its parse tree into XML. SWIG reads annotated C/C++ header files and creates wrapper code (glue code) in order to make the corresponding C/C++ libraries available to the listed languages, or to extend C/C++ programs with a scripting language. Up-to-date SWIG related information can be found at https://www.swig.org A SWIG FAQ and other hints can be found on the SWIG Wiki: https://github.com/swig/swig/wiki License ======= Please see the LICENSE file for details of the SWIG license. For further insight into the license including the license of SWIG's output code, please visit https://www.swig.org/legal.html Release Notes ============= Please see the CHANGES.current file for a detailed list of bug fixes and new features for the current release. The CHANGES file contains bug fixes and new features for older versions. A summary of changes in each release can be found in the RELEASENOTES file. Documentation ============= The Doc/Manual directory contains the most recent set of updated documentation for this release. The documentation is available in three different formats, each of which contains identical content. These format are, pdf (Doc/Manual/SWIGDocumentation.pdf), single page html (Doc/Manual/SWIGDocumentation.html) or multiple page html (other files in Doc/Manual). Please select your chosen format and copy/install to wherever takes your fancy. There is some technical developer documentation available in the Doc/Devel subdirectory. This is not necessarily up-to-date, but it has some information on SWIG internals. Documentation is also online at https://www.swig.org/doc.html. Backwards Compatibility ======================= The developers strive their best to preserve backwards compatibility between releases, but this is not always possible as the overriding aim is to provide the best wrapping experience. Where backwards compatibility is known to be broken, it is clearly marked as an incompatibility in the CHANGES and CHANGES.current files. See the documentation for details of the SWIG_VERSION preprocessor symbol if you have backward compatibility issues and need to use more than one version of SWIG. Installation ============ Please read the Doc/Manual/Preface.html#Preface_installation for full installation instructions for Windows, Unix and Mac OS X using the release tarball/zip file. The INSTALL file has generic build and installation instructions for Unix users. Users wishing to build and install code from Github should visit https://swig.org/svn.html to obtain the more detailed instructions required for building code obtained from Github - extra steps are required compared to building from the release tarball. Testing ======= The typical 'make -k check' can be performed on Unix operating systems. Please read Doc/Manual/Preface.html#Preface_testing for details. Examples ======== The Examples directory contains a variety of examples of using SWIG and it has some browsable documentation. Simply point your browser to the file "Example/index.html". The Examples directory also includes Visual C++ project 6 (.dsp) files for building some of the examples on Windows. Later versions of Visual Studio will convert these old style project files into a current solution file. Known Issues ============ There are minor known bugs, details of which are in the bug tracker, see https://www.swig.org/bugs.html. Troubleshooting =============== In order to operate correctly, SWIG relies upon a set of library files. If after building SWIG, you get error messages like this, $ swig foo.i :1. Unable to find 'swig.swg' :3. Unable to find 'tcl8.swg' it means that SWIG has either been incorrectly configured or installed. To fix this: 1. Make sure you remembered to do a 'make install' and that the installation actually worked. Make sure you have write permission on the install directory. 2. If that doesn't work, type 'swig -swiglib' to find out where SWIG thinks its library is located. 3. If the location is not where you expect, perhaps you supplied a bad option to configure. Use ./configure --prefix=pathname to set the SWIG install location. Also, make sure you don't include a shell escape character such as ~ when you specify the path. 4. The SWIG library can be changed by setting the SWIG_LIB environment variable. However, you really shouldn't have to do this. If you are having other troubles, you might look at the SWIG Wiki at https://github.com/swig/swig/wiki. Participate! ============ Please report any errors and submit patches (if possible)! We only have access to a limited variety of hardware (Linux, Solaris, OS-X, and Windows). All contributions help. If you would like to join the SWIG development team or contribute a language module to the distribution, please contact the swig-devel mailing list, details at https://www.swig.org/mail.html. -- The SWIG Maintainers
Hi,
when using --cccl-muffle
, the script passes the output of cl.exe
to tr
, which output seems to be taken as binary by grep
. Adding -a
to the list of grep
options fixes the issue.
Best.
According to MSDN,
/G (Optimize for Processor) Options
/G is available in all editions of Visual C++, but the compiler can perform more optimizations when /G is used with one of the /O compiler options.
It seems to show that /G
is more like -mtune
.
cccl -I /d/headers
is translated to cl.exe -I -D/headers
, similar for -L
and LIBPATH
.
Before this case:
must be a case which handles the -link
option case.
Makefile:735: update target 'libXau.la' due to: AuDispose.lo AuFileName.lo AuGetAddr.lo AuGetBest.lo AuLock.lo AuRead.lo AuUnlock.lo AuWrite.lo
echo " CCLD " libXau.la;D:/vcpkg_common/downloads/tools/msys2/msys64/usr/bin/sh.exe ./libtool --silent --tag=CC --mode=link cccl --cccl-verbose -ID:/xlinux/installed/x64-windows/debug/../include -Wall -Wpointer-arith -Wmissing-declarations -Wformat=2 -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wbad-function-cast -Wold-style-definition -Wdeclaration-after-statement -Wunused -Wuninitialized -Wshadow -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls -Wlogical-op -Werror=implicit -Werror=nonnull -Werror=init-self -Werror=main -Werror=missing-braces -Werror=sequence-point -Werror=return-type -Werror=trigraphs -Werror=array-bounds -Werror=write-strings -Werror=address -Werror=int-to-pointer-cast -Werror=pointer-to-int-cast /DWIN32 -version-number 6:0:0 -no-undefined -o libXau.la -rpath /D/xlinux/packages/xau_x64-windows/debug/lib AuDispose.lo AuFileName.lo AuGetAddr.lo AuGetBest.lo AuLock.lo AuRead.lo AuUnlock.lo AuWrite.lo
CCLD libXau.la
cl "-nologo" "-Fe.libs/libXau-6.dll" ".libs/AuDispose.obj" ".libs/AuFileName.obj" ".libs/AuGetAddr.obj" ".libs/AuGetBest.obj" ".libs/AuLock.obj" ".libs/AuRead.obj" ".libs/AuUnlock.obj" ".libs/AuWrite.obj" "ink.lib" "-LD"
LINK : fatal error LNK1181: cannot open input file 'ink.lib'
cl exe as GCC allows to specify a file as input, but cccl test.c /path/to/lib
is translated to cl test.c -path/to/lib
which then results in warning D9002 of cl "unknown option ignored", followed by a linker error because of the missing symbols.
Not sure if we should keep the old deprecated options at all - or just go with the "newer" one:
As seen in https://www.gnu.org/software/libtool/manual/html_node/LT_005fINIT.html
instead of
AC_LIBTOOL_WIN32_DLL
AM_PROG_LIBTOOL
the "new" way (since years) should likely be the one (primarily) documented:
LT_INIT [win32-dll]
Hi!
I have noticed that this library is making its way to ConanCenter package repository via this PR: conan-io/conan-center-index#14115
We would like to add there the latest version 1.3 of this library, but there is no current tag for this version right now. Although we can make our way around it, it would be nice to have a tag for it so we can pinpoint that release source bundle.
Would it be possible to have a tag for that 1.3 release? Thank you ๐
link error with
cccl -o conftest.exe -I/d/dev/includes -L/d/dev/libs mconftest.c -lmpir --cccl-verbose
works with
cccl -o conftest.exe -I/d/dev/includes -Ld:/dev/libs mconftest.c -lmpir --cccl-verbose
It looks like link.exe does not like /d/
while the C preprocessor has no issues with that. Possibly paths starting with / could be adjusted; it should be quite save to changed /X/ to X:/ when X is a single letter.
The old MinGW is very inactive1 -- even its domain has expired. Its more active fork MinGW-w64 mainly focuses on building toolchains for distributions to package, and on Windows the two would be MSYS2 and Cygwin.
1 You can't quite call it dead, since the OSDN page is technically kicking with the new GCC releases, and people are actually talking on the mailing list. But they still haven't done 64-bit, which isn't much of a good sign in 2021.
I recommend removing references to MinGW in the README. The references can optionally be replaced with MSYS2 if someone wants to test it -- it's bascially Cygwin but lighter and easier to install packages (via pacman
).
First off: I love this idea, good work.
I'm maintaining a C++ (header-only) library that I'd like to support on major platforms, including at least one windows variant. The library itself is (nearly) portable enough, but I don't use windows personally. Even if I did, humans make poor build servers and so I'm trying to wire up appveyor, a windows-centric build service to prove I can compile and pass my tests, etc.
One of my users is specifically asking for support for MSVC, which is available in that world along with the more usual gcc and autotools. Since I'm already using autotools for my (fairly simple) build, cccl seems like a good fit.
The only issue is I'm having a ducky of a time getting the thing to get up and run. I feel like I'm missing some basic stuff, probably because I've never done any real windows C++ dev. It would be lovely indeed if the documentation called out appveyor configuration specifically.
It would be even better if cccl could supply an example, template repository, configured for appveyor (it's free) that demonstrated some basic build features. My case in particular needs a fairly vanilla libtool invocation to work.
I'd be delighted to share my attempts at integrating cccl & appveyor as a starting point, but I could use some pointers to finish muddling through to a working state.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.