The GUI application and library share some object files but don't
enable object renaming resulting in the second compilation overwriting
the results of the first compilation. This can be fixed by setting
explicit preprocessor flags for one compilation. The actual problem,
however, is that recursive make is used in an inappropriate way; two
Makefiles shouldn't refer to the same source files. In this case,
libslvs should be under src/ and handled by the same Makefile, in
which case the issue would have been obvious when the Makefile was
written in the first place.
Requested by yugami:
> might I suggest explicitly including libGL as well as libpng.
> One of the previous builders errors needed that explicitly added in
As Peter Stuge pointed out, it works anyway if fltk is built with png
support because solvespace uses the flags returned by fltk-config.
If fltk was built with png support enabled, these include -lpng.
For example forward/backward buttons are present on many mouses
but are not used by solvespace. This oops() caused solvespace to
crash whenever those buttons were (accidentally) pressed.
Ubuntu enables GCC's buffer overflow checks by default. In SAVEDptr
union, the path was declared as 'char', even though MAX_PATH memory
was actually allocated. The buffer overflow check mistakenly thought
that the buffer size was only 1 and aborted the program whenever it
tried to read a path from a file.
"There was some small but annoying bugs with the FLTK port:
-cursor disappear sometimes
-not all the area of the windows (graphic and text windows) is accessible
by the mouse after a re-size
-input widget for editing constraints value are not correctly placed"
Microsoft defines an RGB() macro that at one point was compatible with our
version (returning a packed integer containing 8-bit red, green and blue
channels), but is no longer, and the incompatibility led to an awkward
situation in w32main.cpp where we had to restore Microsoft's form of the
macro in order for the commctrl.h header to compile. By renaming the macro
to RGBi()---analogous to the RGBf() macro we already define---we avoid the
hassle entirely.
The libslvs library and CDemo program can now be built by Autotools. A few
code changes were needed for this: C++ comments in C code had to be
converted, constraint.cpp required some massaging, and fltkutil.cpp needed
a stub for InitHeaps().
Place a pre-built copy of generated source files in src/built/, so that
users building SolveSpace from Git without the tools or setup necessary to
generate these can still complete the process.
Makefile.msvc: Use slashes consistently, and added rules to copy files from
src/built/ if needed
configure.ac: Check for presence of src/built/ at configure time
src/Makefile.am: Handle the generated *.table.h files together with
icon*.h; updated the source-generation rules so that the files are created
in builddir, not srcdir; added rules to copy files from src/built/ if
needed
This will allow checkouts of the SolveSpace source tree on Unix and Windows
to use the system's native line endings (i.e. LF vs. CRLF), while keeping
Unix line endings in the repository.
Created using the template at
https://help.github.com/articles/dealing-with-line-endings
The SolveSpace top-level directory was getting a bit cluttered, so
following the example of numerous other free-software projects, we move the
main application source into a subdirectory and adjust the build systems
accordingly.
Also, got rid of the obj/ directory in favor of creating it on the fly in
Makefile.msvc.
The .slvs file I/O code was using "*((type *)pointer) = value" type-punning
dereferences, which are syntactically unwieldy and prone to annoying modern
compilers. A union pointer is more elegant, and better expresses the
polymorphism at issue.
The bundled copies of LibPNG and zlib have been updated to the versions
shipped with FLTK (as these were convenient to build), and I've put in new
static libraries compiled with Visual Studio 2003 .NET. These libraries
link cleanly even with Visual Studio 2013 Express, so they should work for
just about every version of MSVC out there that can compile SolveSpace.
The MSVC makefile is also now a little nicer, and the SpaceWare Input
library header #includes have been adjusted to drop the si/ prefix (for
consistency with how LibPNG/zlib are handled).
With this commit, SolveSpace gains an Autotools build system and a new
platform-dependent backend implemented using the FLTK GUI toolkit. These
will allow the application to be built and run on Linux and other Unix-like
operating systems, and prospectively, MacOS X.
A number of new files have been added:
* Makefile.am: Automake makefile template; this contains some experimental
support for MinGW and MSVC++ builds that needs further development
* ac-aux/ax_fltk.m4: Autoconf M4 macro to locate and query the system's
installation of FLTK; this will eventually be contributed to the GNU
Autoconf Archive
* autogen.sh: Script to bootstrap the Autotools build system, usually for a
tree just checked out from source control
* configure.ac: Source for the Autoconf configure script; note that this
file specifies a version of 2.1, near the top
* fltk/fltkmain.cpp: Main FLTK backend implementation
* fltk/fltkutil.cpp: Utility functions for the FLTK backend
* fltk/xFl_Gl_Window_Group.{H,cxx}: Implementation of a new
Fl_Gl_Window_Group widget for FLTK, needed to facilitate drawing FLTK
widgets on top of OpenGL graphics as SolveSpace does. This has been
submitted to the FLTK project for (hopefully) eventual upstream
inclusion:
http://www.fltk.org/str.php?L2992
The following minor changes are also a part of this commit:
* Makefile.msvc: Define PACKAGE_VERSION=2.1 for the benefit of
solvespace.cpp in MSVC++ builds
* solvespace.cpp: In the About dialog text, use PACKAGE_VERSION rather than
hard-coding the version of the program
* solvespace.h: Don't define the C99 integer types if
HAVE_C99_INTEGER_TYPES is defined, to facilitate MinGW builds
This function previously returned an int32_t. Presuming that it measures
the length of time since the application was started, the 32-bit type would
cause the returned value to wrap from 2^31-1 to -2^31 after a little less
than twenty-five days.
* Added "Show Menu Bar" and "Full Screen" menu items, which will be
implemented in the FLTK interface. These are currently prevented from
appearing in the Win32 interface by the HAVE_FLTK and
HAVE_FLTK_FULLSCREEN macros.
* Moved the "Show Text Window" down below the "Show Toolbar" item, so that
"Show Menu Bar", "Show Toolbar" and "Show Text Window" are in the same
vertical order as their corresponding UI elements typically take on
* Added new platform-dependent routines to back the new menu items:
void ToggleMenuBar(void);
bool MenuBarIsVisible(void);
void ToggleFullScreen(void);
bool FullScreenIsActive(void);
These are stubs in the Win32 code.
* Fleshed out the system header #includes in solvespace.h, and moved them
to the top of the file per convention
* Rewrote the file dialog selection patterns in terms of macros that allow
them to expand to either the FLTK or Windows formats
* Don't use __stdcall in SSGL_CALLBACK, and make SSGL_CALLBACK 'extern "C"'
as OpenGL usually expects function pointers to point to C functions
The "glx" prefix on the names of SolveSpace's various GL helper routines
was confusingly similar to those used by official OpenGL-associated
libraries (e.g. "glu" used by the GL Utility library, and "glX" used by
GLX), and could thus give the erroneous impression that it represented a
system API rather than ordinary application logic. We thus rename these
routines to have an "ssgl" prefix, clearly identifying them with SolveSpace
while retaining some visual kinship to GL function names.
GCC and Clang's -Wfloat-equal warning notes that comparing floating-point
values with == or != may be questionable. But the few instances of these in
SolveSpace are defensibly correct (as discussed with Jonathan), so to keep
folks from getting nervous that a CAD application isn't handling its floats
correctly, we define an EXACT() macro inside which the -Wfloat-equal
warning is disabled. This macro will also serve as a source-code
annotation, like a comment but better.
(The warning is only disabled for Clang, alas, because GCC is particular
about where _Pragma() can be used. This isn't so bad, however, because the
warning is much easier to enable on Clang [thanks to -Weverything], whereas
with GCC it has to be requested explicitly.)
Jonathan Westhues
Marc Britten
Roland Lutz
Andrew Downing
Petteri Aimonen
Ilya Novoselov
Daniel Richard G