wgois / OIS

Official OIS repository. Object oriented Input System

Home Page:https://wgois.github.io/OIS/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Doesn't bootstrap on Cygwin.

JontomXire opened this issue · comments

I've been building stuff on Cygwin for years without problems, but OIS really doesn't like me!

$ ./bootstrap
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: You should add the contents of the following files to 'aclocal.m4':
libtoolize: '/usr/share/aclocal/libtool.m4'
libtoolize: '/usr/share/aclocal/ltoptions.m4'
libtoolize: '/usr/share/aclocal/ltsugar.m4'
libtoolize: '/usr/share/aclocal/ltversion.m4'
libtoolize: '/usr/share/aclocal/lt~obsolete.m4'
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
libtoolize: and rerunning libtoolize and aclocal.
libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
aclocal: macro _LT_COMPILER_PIC' required but not defined aclocal: macro_LT_DECL_SED' required but not defined
aclocal: macro _LT_DECL_SED' required but not defined aclocal: macro_LT_FUNC_STRIPNAME_CNF' required but not defined
autoheader-2.69: error: AC_CONFIG_HEADERS not found in configure.ac
Useless use of /d modifier in transliteration operator at /usr/bin/automake-1.7
line 5985.
configure.ac: no proper invocation of AM_INIT_AUTOMAKE was found.
configure.ac: You should verify that configure.ac invokes AM_INIT_AUTOMAKE,
configure.ac: that aclocal.m4 is present in the top-level directory,
configure.ac: and that aclocal.m4 was recently regenerated (using aclocal).
configure.ac: installing ./install-sh' configure.ac: installing./mkinstalldirs'
configure.ac: installing ./missing' configure.ac:6: installing./config.guess'
configure.ac:6: installing ./config.sub' demos/Makefile.am: installing./depcomp'
/usr/share/automake-1.7/am/depend2.am: am__fastdepCXX does not appear in AM_COND
ITIONAL
/usr/share/automake-1.7/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
src/Makefile.am:5: Libtool library used but LIBTOOL' is undefined src/Makefile.am:5: src/Makefile.am:5: The usual way to defineLIBTOOL' is to add `AC_PROG_LIBTOOL'

src/Makefile.am:5: to configure.ac' and runaclocal' and `autoconf' again.
/usr/share/automake-1.7/am/depend2.am: am__fastdepCXX does not appear in AM_COND
ITIONAL
/usr/share/automake-1.7/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake-1.7/am/depend2.am: am__fastdepCXX does not appear in AM_COND
ITIONAL
/usr/share/automake-1.7/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake-1.7/am/depend2.am: am__fastdepCXX does not appear in AM_COND
ITIONAL
/usr/share/automake-1.7/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
configure.ac:7: error: possibly undefined macro: AM_INIT_AUTOMAKE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:8: error: possibly undefined macro: AM_CONFIG_HEADER
configure.ac:13: error: possibly undefined macro: AM_PROG_CC_C_O
configure.ac:15: error: possibly undefined macro: AM_PROG_LIBTOOL
configure.ac:28: error: possibly undefined macro: AC_PROG_LIBTOOL

Cygwin was fully up to date as of 2 days ago, and I have been using automake etc. for other projects for ages.

I need OIS as a dependency for Ogre.

Was this a build system problem only? I never attempted to use this within Cygwin. If you are sitll around and interested (it's been 3 years!) can you attempt to build the repository now that it uses CMake, just to check on the state of things...

If not, I'll do that myself, it's on the todo list, but not really with an high priority...

I gave up on Ogre in the end, so am not really interested any more, sorry. I wouldn't be at all surprised if it worked much better using CMake.

No problem ;-)
I'm going to attempt to build this in cygwin, and will close the issue if everything works-out

for a start, I'm getting errors just in CMake related to the WIN32 macro when running on Cygwin apparently:

CMake Warning at /usr/share/cmake-3.6.2/Modules/Platform/CYGWIN.cmake:15 (message):
  CMake no longer defines WIN32 on Cygwin!

  (1) If you are just trying to build this project, ignore this warning or
  quiet it by setting CMAKE_LEGACY_CYGWIN_WIN32=0 in your environment or in
  the CMake cache.  If later configuration or build errors occur then this
  project may have been written under the assumption that Cygwin is WIN32.
  In that case, set CMAKE_LEGACY_CYGWIN_WIN32=1 instead.

  (2) If you are developing this project, add the line

    set(CMAKE_LEGACY_CYGWIN_WIN32 0) # Remove when CMake >= 2.8.4 is required

  at the top of your top-level CMakeLists.txt file or set the minimum
  required version of CMake to 2.8.4 or higher.  Then teach your project to
  build on Cygwin without WIN32.
Call Stack (most recent call first):
  /usr/share/cmake-3.6.2/Modules/CMakeSystemSpecificInformation.cmake:36 (include)
  CMakeLists.txt:2 (project)

So, here's the current state of this, and what I think about it:

Under cygwin, the current code for Windows, nor Linux will build:

  • Linux code will want to include linux/input.h in the force feedback code. As this is not done via Xorg obviously
  • Windows needs the DirectX SDK... CMake in Cygwin doesn't seems to be able to deal with that.

What I think about the situation : The Cygwin usecase seems a bit strange to me. I don't thing this is currently worth putting effort unless somebody really wants to use this. And I'm unsure on how to go around touching some of theses OS specific issues in the Cygwin context : Are we on Windows dealing with Windows stuff, or on Unix dealing with Unix stuff?

in the current state, I'm labeling this as "wontfix" and closing the issue.