swig / cccl Goto Github PK

Unix cc compiler to Microsoft's cl compiler wrapper

License: GNU General Public License v3.0

Shell 97.55% Makefile 0.26% M4 2.19%

cccl's Introduction

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

cccl's People

Contributors

Stargazers

Watchers

cccl's Issues

-I and -L with space do not work

cccl -I /d/headers is translated to cl.exe -I -D/headers, similar for -L and LIBPATH.

README: replace / add to deprecated AM_PROG_LIBTOOL and AC_LIBTOOL_WIN32_DLL

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]

README: get rid of MinGW?

The old MinGW is very inactive¹ -- 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.

¹ 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).

-m<arch> options should be mapped to /arch

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.

Option -link tries to link ink.lib

Before this case:

cccl/cccl

Line 129 in ac88ffd

-l*)

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'

Wish: Appveyor-specific documentation, example project & build

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.

--cccl-muffle in msys/mingw requires grep -a

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.

MinGW/cygwin paths are passed to cl.exe as option

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.

[request] Add 1.3 release tag

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 😄

Adjust absolute linker paths to use directory

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.

swig / cccl Goto Github PK

cccl's Introduction

cccl's People

Contributors

Stargazers

Watchers

Forkers

cccl's Issues

/G (Optimize for Processor) Options

Recommend Projects

Recommend Topics

Recommend Org

Jobs