| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
We don't need this much ad hoc complexity in the build system to find
gobject-2.0 and its tools.
GObject depends on GLib; GThread does not exist any more, as has been
subsumed into GLib; the AM_PATH_GLIB_2_0 m4 macro is deprecated in
favour of just using PKG_CHECK_MODULES.
|
|
|
|
|
|
|
|
| |
Let's use modern, idiomatic gtk-doc to generate the API reference:
- use XInclude
- stop using SGML mode with XML files
- drop version.xml and use the gtk-doc package entities
|
|
|
|
|
|
|
|
| |
Always use the system one, since:
- we require gobject-introspection at build time
- the local copy always goes out of sync
- the system copy is actually maintained
|
|
|
|
|
| |
The commit log is in Git — and so is the ChangeLog file. There's no need
to leave the file around.
|
|
|
|
| |
Almost 10 years old, and completely out of date.
|
|
|
|
|
|
|
|
|
| |
No library ships these files, and they have always been questionable to
begin with.
When building from a separate prefix, using PKG_CONFIG_PATH to modify
the pkg-config search path is a better option that just pointing to the
source directory of the dependencies.
|
|
|
|
|
| |
It's 12 years old, and hopelessly out of date. All operating systems
using RPM have a package for ATK anyway.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Update the autotools scripts so that we can copy the Visual Studio 2010
project files and update them to obtain the Visual Studio 2017 projects.
As the format of the toolset version is different, allow a version number
string for the toolset version and use it if specified, otherwise just
create the toolset version string as we did before.
Note that Visual Studio 2015 and 2017 aims to be compatible in terms of
CRT usage, so it should be possible to use 2015-built binaries with
2017-built binaries.
|
| |
|
|
|
|
|
| |
It was suggested that the project be moved to win32/, so that one will
need to go one less layer down into the tree to reach the project files.
|
| |
|
| |
|
|
|
|
| |
This is needed so that we can generate the .pc file from the .pc.in file.
|
| |
|
| |
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=760323
|
| |
|
|
|
|
|
|
|
|
| |
Since we are now using the common autotools module for generating the
complete Visual Studio ATK projects, we don't need to check for Python
anymore during configure, so we can just drop the Python part.
https://bugzilla.gnome.org/show_bug.cgi?id=755114
|
|
|
|
|
|
| |
This "adds" Visaul Studio 2015 projects by doing what we did before:
copying the Visual Studio 2010 projects and replacing items in there
as necessary.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
This will eventually be replaced by AX_COMPILER_FLAGS
https://bugzilla.gnome.org/show_bug.cgi?id=744413
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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 would move the generation of the ATK Visual C++ 2008/2010 project
to Python 2/3 scripts from autotools scripts. This would have the
following advantages:
-Reduce congestion in the autotools files, most notably atk/Makefile.am,
and make everything that concerns the completion of MSVC project files
fo under build/
-Easier to maintain and test, as a standard installation of Python (even
on Windows) is enough to generate the Project files, and this can still
be easily called during 'make dist'.
-Also paves the first steps for people wanting to build ATK from a GIT
checkout, as this will help simplify the process
There is now a dependency on Python 2/3 for people that are wishing to do
'make dist', as naturally the scripts to do the Visual C++ project
generation is done with Python, but since one is likely going to generate
the .gir files for ATK when doing 'make dist'/'make distcheck', this is
satisfied as the scripts used to generate the .gir files are Python 2.6+
scripts as well.
https://bugzilla.gnome.org/show_bug.cgi?id=690145
|
| |
|
| |
|