summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Release GObject-Introspection 1.46.01.46.0gnome-3-18Emmanuele Bassi2015-09-221-2/+2
|
* Update glib annotations from git masterRico Tzschichholz2015-09-142-7/+20
|
* giscanner/ccompiler.py: Improve CFLAGS handlingChun-wei Fan2015-09-081-0/+16
| | | | | | | | Some packages such as GEGL set macro defines directly into CFLAGS, and distutils don't handle those with quotes well, so we need to deal with them seperately. https://bugzilla.gnome.org/show_bug.cgi?id=753428
* regress: Add a test for (nullable)Colin Walters2015-09-037-0/+138
| | | | Related to: https://bugzilla.gnome.org/719966
* Update glib annotations from git masterRico Tzschichholz2015-09-033-217/+367
|
* giscanner: Use Distutils to Build Dumper ProgramChun-wei Fan2015-09-012-119/+172
| | | | | | | | | | | | | | | | | | | Add compile() and link() functions in ccompiler.py to call distutils.ccompiler's compiler() and link() functions, so that we can in turn call them from dumper.py as needed. Note that for linking the dumper program when building with libtool, we are still using the original method of constructing the link command line and running that command line, as distutils and libtool do not get along well with each other. For non-libtool builds, such as MSVC builds, we would link the dumper program using distutils. For MSVC builds, we need to ignore mt.exe failing to find a .exe.manifest file as Visual Studio 2010+ do not generate such files during linking, and it is done by distutils as Python 2.7.x is built with Visual Studio 2008, which do generate such manifest files during the build. https://bugzilla.gnome.org/show_bug.cgi?id=753428
* g-ir-scanner: Support multiple arguments for compilerMarc-Antoine Perennou2015-08-241-1/+1
| | | | | | | | This should allow `CC='ccache gcc'` or the like to work. https://bugzilla.gnome.org/show_bug.cgi?id=753949 Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
* Release GObject Introspection 1.45.41.45.4Emmanuele Bassi2015-08-211-1/+1
|
* Update the GLib introspection dataEmmanuele Bassi2015-08-213-347/+413
| | | | Against GLib 2.45.6.
* scanner: use open() as os.fdopen as context managersDieter Verfaillie2015-08-217-79/+68
| | | | | | Ensures files are correctly and immediately closed. https://bugzilla.gnome.org/show_bug.cgi?id=751926
* scanner: fix cachestore raceDieter Verfaillie2015-08-211-9/+8
| | | | | | | | Using tempfile.mkstemp should prevent the temp file from being cleaned while it might still be used by another process. https://bugzilla.gnome.org/show_bug.cgi?id=751926
* g-ir-compiler: message when arguments are wrongBen Boeckel2015-08-041-0/+9
| | | | | | | | Otherwise the error is "no input files" which is very confusing. https://bugzilla.gnome.org/show_bug.cgi?id=753160 Signed-off-by: Ben Boeckel <mathstuf@gmail.com>
* Revert "dumper.py: Use Distutils to Build Dumper Program"Chun-wei Fan2015-07-312-164/+157
| | | | | | | | | This reverts commit 7ce646db1cb0842db2089df671b17081f82f2b0a. Apparently this patch caused introspection build breakage for gnome-shell, as problems occurred during linking for libgnome-volume-control. Please see bug 728313 comment 105 for more details.
* dumper.py: Use Distutils to Build Dumper ProgramChun-wei Fan2015-07-302-157/+164
| | | | | | | | | | | | | | | | Add compiler() and link() functions in ccompiler.py to call distutil.ccompiler's compile() and link() functions, so that we can in turn call them from dumper.py to build the dumper program. As distutils don't get along well with libtool libraries (ie .la files), we can deduce the libraries to link from using the file name .la file and include $(builddir)/.libs in the linking stage. For MSVC builds, we need to ignore mt.exe failing to find a .exe.manifest file as Visual Studio 2010+ do not generate such files during linking, and it is done by distutils as Python 2.7.x is built with Visual Studio 2008, which do generate such manifest files during the build. https://bugzilla.gnome.org/show_bug.cgi?id=728313
* sourcescanner.py: Use Distutils for PreprocessingChun-wei Fan2015-07-304-41/+171
| | | | | | | | | | | | | | | | | | Add a preprocess() function in ccompiler.py so that it will call the preprocess() method of the distutils.ccompiler class, and make use of it from sourcescanner.py. As we would need to set up the options (include paths, macros, undefs) to pass into the preprocessor (and later for the compiler), we have a new private function that translates what we have from the rest of giscanner so that it could be passed to distutils.ccompiler in a way that it understands. Also, as the MSVCCompiler classes in distutils do not provide a preprocess() implementation, we provide our own so that we can use it when preprocessing, via distutils, through subclassing MSVCCompiler. https://bugzilla.gnome.org/show_bug.cgi?id=728313
* giscanner/ccompiler.py: Initiate Distutils Compiler InstanceChun-wei Fan2015-07-302-78/+113
| | | | | | | | | | | | | | | | | | | | | | | | | | This updates the __init__ constructor method of CCompiler so that distutils can be used, with some environment or user-supplied options to create the compiler instance that is appropriate with the platform that the giscanner scripts are being run on, and sets some specific environment for the compilers as necessary. This also adds a check_is_msvc() method that will progressively replace calls in the other giscanner scripts that attempt to check for CC=cl (or so), where a part of which is done in this patch. This is done for dumper.py as well as it needs to be updated in this patch to use the updated ccompiler.py which uses distutils to initiate the compiler instance. Also, as we have been using the --library option on Windows to pass in the library (not DLL) to deduce the correct DLL to link to in the introspection files for some time, we no longer need to make a copy of the library (.lib) to introspect that matches the <namespace>-<namespace_version>.lib convention, but use the libraries that were passed in with --library directly, so that we can link the dumper program during the introspection build. Please note that this also partially reverts commit c9cfa2b as the distutils items are clearly needed for these to work. https://bugzilla.gnome.org/show_bug.cgi?id=728313
* MSVC Builds: Update README.txt'sChun-wei Fan2015-07-302-27/+5
| | | | | | | Remove mentions about the GCC requirement for building the introspection files, as that is no longer needed. https://bugzilla.gnome.org/show_bug.cgi?id=728313
* MSVC Builds: Drop GCC RequirementChun-wei Fan2015-07-303-25/+2
| | | | | | | | | As we are running the preprocessor without using stdin as its input, we can now drop the MSVC build-time dependency on a MinGW/GCC installation for introspection files, which means we also don't need to supply definitions for time_t anymore. https://bugzilla.gnome.org/show_bug.cgi?id=728313
* giscanner/sourcescanner.py: Use Tempfiles For ParsingChun-wei Fan2015-07-301-31/+47
| | | | | | | | | | | | | As we attempt to move giscanner to use distutils for preprocessing and building the introspection dumper program, we need to update _parse(), where the preprocessor is called, to not use stdin and stdout for the preprocessor input and output, as distutils do not accept such usage. The added bonus for this change is that MSVC builds can be done without using MinGW/GCC as a helper, as the '-' flag for preprocessing from stdin was the hindrance to that. https://bugzilla.gnome.org/show_bug.cgi?id=728313
* girepository: Remove "optimization" for found prefixesJasper St. Pierre2015-07-271-11/+0
| | | | | | | | | | | | | | | This optimization is bugged and broken in the case of certain libraries. GNOME uses a lot of prefixes with "G", so we'll almost always have found the prefix. This is specifically a problem for something like GXml.xDocument, which uses a type name starting with a lower-case letter, which fools the prefix logic, but we're also fooled by the "G" appearing in GLib and Gio. A more sophisticated version of this check would have three passes: check prefix with type-case, check prefix without type-case, global search, but this is an edge case and it doesn't feel worth it to write.
* scanner: Fix stray comment in previous commitColin Walters2015-07-271-1/+0
| | | | Forgot to amend.
* scanner: Recognize __signedColin Walters2015-07-271-0/+2
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=752904
* MSVC Introspection Builds: Make Cairo Note ClearerChun-wei Fan2015-07-271-2/+2
|
* MSVC Builds: Fix Script Generation CommandChun-wei Fan2015-07-252-4/+4
| | | | Update the property sheets, to reflect the changes in the last commit.
* build/: Fix Incorrect Naming of ScriptChun-wei Fan2015-07-251-0/+0
|
* MSVC Builds: Update to Fix Build of ScriptsChun-wei Fan2015-07-246-150/+40
| | | | | | | | | Update the custom build steps that is used to generate the scripts in tools/, so that the Visual Studio builds can be done successfully. Also assume that one will be using the same Python release series for x86 and x64 builds, while we still leave room for one to customize these if necesssary.
* MSVC Builds: Clean Up And Fix the ProjectsChun-wei Fan2015-07-243-26/+0
| | | | | | | We use the __declspec(dllexport) mechanism for exporting the symbols from the girepository DLL during the build since some time ago, but forgot to remove the .def-generating items from the project files, notably the MSVC 2010+ ones, which could have well broke those builds. Sorry.
* MSVC Builds: Generate The Tools ScriptsChun-wei Fan2015-07-245-63/+121
| | | | | | | | | | | | | Since commit 7e00146, the scripts in tools/ are being generated from tools/g-ir-tool-template.in, so we need to deal with this to fix Visual Studio Builds. Add a simple script to generate the Python tools scripts by splitting up the gen-cairo-gir.py script and rename gen-cairo-gir.py to gen-win32-cairo-gir.py to make things clearer to people, and adjust the corresponding files accordingly. Make sure everything here use UNIX line endings, for consistency's sake.
* MSVC .gir Builds: Allow More Flexibility for CairoChun-wei Fan2015-07-242-8/+22
| | | | | | | | | | | Allow one to pass in the cairo-gobject DLL filename for generating cairo-1.0.gir, as the DLL filename for Cairo-GObject may vary between different setups, if needed. Display a note telling the user that he/she needs to ensure that the DLL name used is correct so that programs and scripts using the cairo-1.0.typelib can run correctly. Also clean up the generation of cairo-1.0.gir a bit by directly generating the cairo-1.0.gir in build\ only during the build.
* build/gi-inrtospection-msvc.mak: Allow Libtool Style NamesChun-wei Fan2015-07-221-1/+5
| | | | | | | ...for the cairo-1.0.gir, as there may be still people that prefer to use it, for some reason. For the GLib and GI DLLs, the DLL name is deduced from the --library argument (i.e. the filename of the .lib) passed in to g-ir-scanner, so that part is not affected by this change.
* build/gen-cairo-gir.py: Clean Up A BitChun-wei Fan2015-07-221-1/+0
| | | | | | | We don't really need the --vsver option anymore, so we can just drop it. The NMake Makefile does the handling of the DLL name according to the Visual Studio version used, according to the DLL naming convention that we used in the GNOME parts of the GTK+ stack).
* Update glib annotations from glib 2.45.4Rico Tzschichholz2015-07-211-0/+12
|
* test: Add a test for GList containing GType.Christoph Reiter2015-07-057-0/+146
| | | | | | See https://bugzilla.gnome.org/show_bug.cgi?id=749696 https://bugzilla.gnome.org/show_bug.cgi?id=751978
* Release 2.45.31.45.3Florian Müllner2015-07-031-2/+2
|
* Update glib annotations from git masterRico Tzschichholz2015-07-012-193/+360
|
* Add missing maintainer tools to EXTRA_DISTDieter Verfaillie2015-06-291-1/+4
|
* tests: add missing fixed-size array annotation testsDieter Verfaillie2015-06-291-0/+55
| | | | | | Cases where fixed-size has no value and fixed-size has a non-integer value where not yet tested. Found thanks to coverage.py
* tests: Update misc/pep8.py to 1.6.2Dieter Verfaillie2015-06-299-388/+626
| | | | | Updated from: https://raw.githubusercontent.com/jcrocholl/pep8/1.6.2/pep8.py
* tests: fix commentDieter Verfaillie2015-06-291-1/+1
| | | | | Code uses LOG_COMPILER, comment mistakenly still mentioned TESTS_ENVIRONMENT.
* tests: go through 'env' for all TESTS_ENVIRONMENTDieter Verfaillie2015-06-291-1/+1
| | | | | we already go through 'env' for all other TESTS_ENVIRONMENT statements, reason to not do so here too...
* tests: don't repeat --warn-all --reparse-validate argumentsDieter Verfaillie2015-06-292-2/+1
| | | | | "--warn-all --reparse-validate" is already contained in $(INTROSPECTION_SCANNER_ARGS), no need to repeat
* scanner: remove unused importsDieter Verfaillie2015-06-292-7/+1
|
* scanner: remove unused param_namesDieter Verfaillie2015-06-291-2/+0
| | | | | | we haven't been emitting the warning for about six years (see 7dbbda9abea9882d2c98726f382a905fa8738706) so remove the leftovers...
* scanner: fix broken assert messageDieter Verfaillie2015-06-291-1/+1
| | | | | | | | 288b339edf262f1dba4e87a9faef46cc79749bd5 changed the signature from def _parse_type_second_pass(self, parent, node, typeval): to def _parse_type_array_length(self, siblings, node, typeval) but failed to change the assert statement accordingly.
* scanner: document LibtoolImporter.load_module()Dieter Verfaillie2015-06-291-9/+6
| | | | | | | | | | | | | | | | | | It was reported by HeBD on #introspection that Python modules use the .pyd extension on windows, not .dll. The simple fix would have been to just rename to .pyd, but we started investigating the possibility of acquiring the suffix tuple(s) via imp.get_suffixes() instead. Which led to the discovery that imp.load_module() simply ignores the first item of said tuple. Thus, there is no use in pretending it to be of any importance in this case so we set it to an empty string. imp_load_module() source for: Python 2.6.9 : https://hg.python.org/cpython/file/fcb3ec2842f9/Python/import.c#l3021 Python 2.7.10: https://hg.python.org/cpython/file/15c95b7d81dc/Python/import.c#l3148 and just to be future-proof: Python 3.4.3 : https://hg.python.org/cpython/file/b4cbecbc0781/Lib/imp.py#l220
* tools: move verbump.py from tools to misc...Dieter Verfaillie2015-06-292-1/+1
| | | | ... so it lives next to the rest of the maintainer utilities.
* tools: use a template to generate the tools scriptsDieter Verfaillie2015-06-294-128/+10
| | | | | | g-ir-annotation-tool, g-ir-doc-tool and g-ir-scanner where identical except for the module and function being invoked. Avoid code duplication and generate these from a common template.
* tools: add support for PyDev remote debugger.Dieter Verfaillie2015-06-294-18/+59
|
* tools: make g-ir-annotiotion-tool, g-ir-doc-tool and g-ir-scanner ↵Dieter Verfaillie2015-06-293-51/+33
| | | | | | 'relocatable' at runtime. https://bugzilla.gnome.org/show_bug.cgi?id=620566
* scanner: future-proof cachestore version hashingDieter Verfaillie2015-06-291-2/+1
| | | | | | | Python 3 does not write .pyc files like Python 2 used to do but instead put's them in a __pycache__ directory. Simply compute the version hash using the .py files instead.
View Lorry Controller Status