New checkout fails to build

Hi guys-

I have been building CVS checkouts for a few months with Visual Studio 2008 on a Windows 7 machine.

I just checked out the whole -current SVN tree and went to build it. Everything worked except for the slv2 library. slv2 fails because it can’t find some standard system include files:

3>help - 0 error(s), 0 warning(s)
1>f:audbuildsvnaudlib-srcslv2srcslv2_internal.h(26) : fatal error C1083: Cannot open include file: ‘stdbool.h’: No such file or directory
1>world.c
1>…lib-srcslv2srcworld.c(24) : fatal error C1083: Cannot open include file: ‘dirent.h’: No such file or directory
1>values.c
1>…lib-srcslv2slv2/values.h(26) : fatal error C1083: Cannot open include file: ‘stdbool.h’: No such file or directory
1>value.c
1>…lib-srcslv2slv2/value.h(26) : fatal error C1083: Cannot open include file: ‘stdbool.h’: No such file or directory
1>util.c

1>slv2 - 35 error(s), 2 warning(s)
========== Build: 1 succeeded, 1 failed, 28 up-to-date, 1 skipped ==========


…if I was on a *nix machine, I’d just add the correct include directories to the include path, and go away happy (though these particular includes would just be in /usr/include, which would almost certainly be in the include path already). On a Windows machine, I am lost… the system doesn’t seem to have standard include files (or a working way to find files… I’m going to see if I can download “find” and “grep” for windows after work, because this windows 7 search thing is worse than useless).

Anyway, what am I doing wrong here? I can hack it into compliance once I find wherever Windows hides its include files (maybe they come with the compiler, since the OS is all pre-compiled binaries?)- but I’m guessing that I could also twiddle something in the Audacity project file to tell all the libraries included to look in a standard include path.

Thanks!

(This is a brand new SVN checkout of the -current branch.)

You know you posted in the Windows User forum, right, not Compiling Audacity?

Koz

I wasn’t aware that CVS was still being used - the developers have switched over to SVN, so I’m not sure how maintained CVS is now.

http://code.google.com/p/audacity/source/checkout

Doh, sorry, will re-post in the correct forum- and yes, this is the SVN tree, not the CVS tree.

No problem, I’ve moved this (and left a shadow post for redirection).

I probably can’t offer much help as I’ve only ever built on 'nix, but what’s this?

f:audbuildsvnaudlib-srcslv2srcslv2_internal.h(26)

It’s an odd looking path, and what’s the “(26)”? Is that NFW (Normal for Windows)?

No errors during compiling?

Hi speef!

I am getting the same problem when I try to build slv2. Are you aware that it is not necessary to build it in order to compile and run Audacity? I am not familiar with slv2 so I do not know what it might add to Audacity. I did search my computer for stdbool.h and found it in the source sections of three other Open Source programs (one of which is GnuWin32srcdiffutils2.8.7diffutils-2.8.7-srclib). You might try grabbing a copy from elsewhere (it was not in the Audacity CVN as of 1.3.9-1.3.11 and is not in Audacity SVN). If you have problems finding a copy I can send you…ah it is very short so here…

/* Copyright (C) 2001, 2002, 2003 Free Software Foundation, Inc.
   Written by Bruno Haible <haible@clisp.cons.org>, 2001.

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 2, or (at your option)
   any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program; if not, write to the Free Software Foundation,
   Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */

#ifndef _STDBOOL_H
#define _STDBOOL_H

/* ISO C 99 <stdbool.h> for platforms that lack it.  */

/* Usage suggestions:

   Programs that use <stdbool.h> should be aware of some limitations
   and standards compliance issues.

   Standards compliance:

       - <stdbool.h> must be #included before 'bool', 'false', 'true'
         can be used.

       - You cannot assume that sizeof (bool) == 1.

       - Programs should not undefine the macros bool, true, and false,
         as C99 lists that as an "obsolescent feature".

   Limitations of this substitute, when used in a C89 environment:

       - <stdbool.h> must be #included before the '_Bool' type can be used.

       - You cannot assume that _Bool is a typedef; it might be a macro.

       - In C99, casts and automatic conversions to '_Bool' or 'bool' are
         performed in such a way that every nonzero value gets converted
         to 'true', and zero gets converted to 'false'.  This doesn't work
         with this substitute.  With this substitute, only the values 0 and 1
         give the expected result when converted to _Bool' or 'bool'.

   Also, it is suggested that programs use 'bool' rather than '_Bool';
   this isn't required, but 'bool' is more common.  */


/* 7.16. Boolean type and values */

/* BeOS <sys/socket.h> already #defines false 0, true 1.  We use the same
   definitions below, but temporarily we have to #undef them.  */
#ifdef __BEOS__
# include <OS.h> /* defines bool but not _Bool */
# undef false
# undef true
#endif

/* For the sake of symbolic names in gdb, we define true and false as
   enum constants, not only as macros.
   It is tempting to write
      typedef enum { false = 0, true = 1 } _Bool;
   so that gdb prints values of type 'bool' symbolically. But if we do
   this, values of type '_Bool' may promote to 'int' or 'unsigned int'
   (see ISO C 99 6.7.2.2.(4)); however, '_Bool' must promote to 'int'
   (see ISO C 99 6.3.1.1.(2)).  So we add a negative value to the
   enum; this ensures that '_Bool' promotes to 'int'.  */
#if !(defined __cplusplus || defined __BEOS__)
# if !@HAVE__BOOL@
#  if defined __SUNPRO_C && (__SUNPRO_C < 0x550 || __STDC__ == 1)
    /* Avoid stupid "warning: _Bool is a keyword in ISO C99".  */
#   define _Bool signed char
enum { false = 0, true = 1 };
#  else
typedef enum { _Bool_must_promote_to_int = -1, false = 0, true = 1 } _Bool;
#  endif
# endif
#else
typedef bool _Bool;
#endif
#define bool _Bool

/* The other macros must be usable in preprocessor directives.  */
#define false 0
#define true 1
#define __bool_true_false_are_defined 1

#endif /* _STDBOOL_H */

The other versions are similar but not identical–maybe equivilant. Now that I have looked at them and seen that they all just #define the various ways of saying bool, true and false, I would suggest NOT including it then fix all the errors which result by doing so–although I do not have the skills to do this (it seems to be something about trying to compile C on C++) you might have better luck–I hope so!

From the slv2 documentation:

SLV2 is a host library to simplify the discovery, loading, and use of LV2 plugins (> http://lv2plug.in> ).

SLV2 is written in standard C99, and depends only on the Redland RDF library (> http://librdf.org> ). It should be portable to any system with Redland, and is tested on various GNU/Linux distributions (often), and MacOS X (occasionally).

lv2 plug-ins are the successor to LADSPA plug-ins.
No mention of Windows support for slv2.

Here is what LV2 support provides in Audacity, if you can build the slv2 library. It does not build on Windows (Bug 55) precisely because it’s written in C99 - I understand it needs a lot of work translating calls into C++.