| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Previous one still have references to a wrong
glib dependency, CVS, etc
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Change needed by the MINGW project.
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
|
| |
|
| |
|
|
|
|
|
|
| |
Be a bit more careful when copying and updating the property sheets, so that
we don't accidently change fields with '10' in them that are actually not
indicating the Visual Studio version.
|
|
|
|
|
|
|
|
|
| |
Like the Visual Studio 2012 projects, the Visual Studio 2013 project files
are only slightly different from the Visual Studio 2010 files, in more or
less the same manner. We can thus easily provide out-of-box support for
building under Visual Studio 2013 by expanding on the scripts used to
provide support for the Visual Studio 2012 projects, without adding much
maintainance overhead.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, due to the way that Visual Studio 2010+ projects are handled,
the "install" project does not re-build upon changes to the sources, as it
does not believe that its dependencies have changed, although the changed
sources are automatically recompiled. This means that if a part or more
of the solution does not build, or if the sources need some other fixes
or enhancements, the up-to-date build is not copied automatically, which
can be misleading.
Improve on the situation by forcing the "install" project to trigger its
rebuild, so that the updated binaries can be copied. This does trigger an
MSBuild warning, but having that warning is way better than not having an
up-to-date build, especially during testing and development.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since 41442d82 we no longer generate atk.def, but we were still reading
it when linking libatk on MinGW. This was causing a build failure:
CC atkwindow.lo
CC atk-enum-types.lo
/usr/bin/i686-w64-mingw32-windres atk.rc atk-win32-res.o
CCLD libatk-1.0.la
libtool: link: symbol file `atk.def' does not exist
make[3]: *** [libatk-1.0.la] Error 1
https://bugzilla.gnome.org/show_bug.cgi?id=730859
|
|
|
|
| |
Add the builddir to the include path so atk/atkobject.h is found.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Clarifying that the atk types should be already registered
before calling this method.
https://bugzilla.gnome.org/show_bug.cgi?id=729922
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=729752
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Update the config.h.win32.in template to define _ATK_EXTERN as
__declspec(dllexport) extern for Visual Studio builds, so that the public
symbols and variables can be exported during the build, and generating
atk.def will no longer be needed. Update the projects and property sheets
accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=728031
|
|
|
|
|
|
|
|
|
|
| |
As the format of the Visual Studio 2012 project files are not much
different as compared to the 2010 ones, we can use some simple autotools
scripts to copy the Visual Studio 2010 project file items, and replacing
Visual-Studio-version-specific strings as necessary, so we provide support
for it quite easily without much maintenance overhead.
https://bugzilla.gnome.org/show_bug.cgi?id=691991
|
|
|
|
|
|
|
|
|
| |
Update the autotools files to determine the compiler directive used to mark
a symbol for export, and use the appropriate CFLAGS as necessary. Also
make MinGW builds not to generate atk.def and attempt to generate and
install a Visual Studio .lib file from there.
https://bugzilla.gnome.org/show_bug.cgi?id=728031
|
|
|
|
|
|
|
|
|
| |
This makes sure that the generated enumeration header include
atk/atkversion.h, and decorate the symbols there with ATK_AVAILABLE_IN_ALL.
Also, make sure that the generated enumeration source file includes
config.h before including atk.h.
https://bugzilla.gnome.org/show_bug.cgi?id=728031
|
|
|
|
|
|
|
|
| |
Make sure that config.h is included first in all the C-sources in atk/ so
that the build-time definitions of _ATK_EXTERN can be used during the
build of the ATK library.
https://bugzilla.gnome.org/show_bug.cgi?id=728031
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This includes atk/atkversion.h in all the public headers, either directly
or via atk/atkobject.h, and annotates the public symbols in the headers,
which all lead to _ATK_EXTERN via one of ATK_AVAILABLE_IN_ALL,
ATK_AVAILABLE_IN_X_Y, ATK_DEPRECATED, ATK_DEPRECATED_FOR,
ATK_DEPRECATED_IN_X_Y or ATK_DEPRECATED_IN_X_Y_FOR, depending on which
stable release series the API was introduced or deprecated.
_ATK_EXTERN which can then be defined in a way during the build, so that
these symbols can be exported automatically using compiler directives.
Also use _ATK_EXTERN for ATK_VAR in atk/atkmisc.h during the build so that
variables can also be properly exported.
https://bugzilla.gnome.org/show_bug.cgi?id=728031
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds version macros, like what is now done in GLib, GTK+ and Clutter,
so that these macros can be used in public headers to:
-Prepare for using a visibility-based (or __declspec(dllexport)method to
export the public APIs during the build. These macros are marked for 2.x
stable releases as ATK_AVAILABLE_IN_X_Y, and ATK_AVAILABLE_IN_ALL for APIs
introduced on or before the ATK-2.0.0 release.
-Add ATK_DEPRECATED_IN_X_Y macros for use on APIs that are deprecated
in 2.x, and ATK_DEPRECATED for those deprecated earlier. This
is also used to export the deprecated APIs using the visibility-based/
__declspec(dllexport) method.
https://bugzilla.gnome.org/show_bug.cgi?id=728031
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|