summaryrefslogtreecommitdiff
path: root/Makefile.introspection
Commit message (Collapse)AuthorAgeFilesLines
* Revert "Windows port: Work arount MSYS weirdness where it changes --libtool= ↵Ray Donnelly2018-06-201-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | command line arguments." A very old version of MSYS performed normalization during path conversion so "/bin/sh ../../libtool" became "c:/opt/msys/1.0/bin/libtool" ("sh .." was considered a single folder), it doesn't do this any more; nor does MSYS2. Also, the old comment was incorrect. It claimed: "This continues to reuse the LIBTOOL variable from automake if it's set, but works around some MSYS weirdness: When running g-ir-scanner, MSYS changes a command-line argument --libtool="/bin/sh ../../libtool" into --libtool=c:/opt/msys/1.0/bin/libtool. So just use sh.exe without path because we already "know" where the libtool configure produced is." .. yet the actual code was changed to: _gir_libtool = $(if $(findstring MINGW,$(shell uname -s)),--libtool="$(top_builddir)/libtool",$(if $(LIBTOOL),--libtool="$(LIBTOOL)")) .. so in fact, if $(uname -s) contained "MINGW", then --libtool ignored the LIBTOOL variable from automake and used $(top_builddir)/libtool instead, at the very least, removing all trace of $(SHELL) from it. Now that $(SHELL) has been re-introduced into libtool, it must not doubly appear in resolve_windows_libs in ccompiler.py, as otherwise sh.exe will try to execute sh.exe and that clearly will not work. I've left some MSYS-specific hacks in dumper.py, some of which could probaly be removed safely now (execution through a temporary shell script), but I've opted to leave it as is for now. This reverts commit 33bbdce144d275b693752f0bc2c2f292deda854e.
* Allow overriding of the host os nameNicola Fontana2018-01-251-1/+1
| | | | | | | | Added the GI_HOST_OS environment variable to eventually specify the host OS explicitely. It fall backs to os.name to retain backward compatibility. https://bugzilla.gnome.org/show_bug.cgi?id=761985
* Makefile.introspection: Add variable for C includesEvan Nemerson2017-02-161-0/+4
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=678749
* Allow overriding of dlltool nameNicola Fontana2016-02-161-1/+1
| | | | | | | | Allow to override it with the DLLTOOL environment variable, leaving "dlltool" as a fallback when not defined so backward compatibility is ensured. https://bugzilla.gnome.org/show_bug.cgi?id=761984
* Use PKG_CONFIG when running g-ir-scannerNicola Fontana2016-02-161-1/+1
| | | | | | | While cross-compiling, "$PKG_CONFIG" is not "pkg-config", so do not assume it when calling g-ir-scanner to build up the base gir files. https://bugzilla.gnome.org/show_bug.cgi?id=761983
* Makefile.introspection: pass CC to scannerDieter Verfaillie2015-04-181-1/+1
| | | | | | Extends commit 92d9c38 to also pass CC to g-ir-scanner. https://bugzilla.gnome.org/show_bug.cgi?id=700066
* Makefile.introspection: pass *FLAGS to scannerRyan Lortie2015-03-301-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | automake provides a few mechanisms for setting the various user-defined variables CFLAGS, CPPFLAGS, LDFLAGS that g-ir-scanner passes through to the C compiler. - can be set in the environment - can be given as a commandline option to configure: ./configure LDFLAGS=-L/usr/local/lib - can be given as a commandline option to make: make LDFLAGS=-L/usr/local/lib Currently, g-ir-scanner only checks for the variables in the environment, whereas the correct value to use will always be the value that is available from the Makefile, eg: $(LDFLAGS). We could pass these variables as new arguments to the scanner, but the easiest thing to do is promote them to the environment where the scanner can see them. https://bugzilla.gnome.org/show_bug.cgi?id=722887
* Makefile.instrospection: search for MINGW instead of MINGW32Ignacio Casal Quinteiro2015-03-251-1/+1
| | | | | | | | On mingw64 the right string to search is MINGW64 so instead of search for a specific one we just search for the generic MINGW. Thanks Alexey for finding out this problem. https://bugzilla.gnome.org/show_bug.cgi?id=746740
* Fix indentation on pretty printed Makefile rulesRobert Ancell2013-06-061-2/+2
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=701679
* scanner: Allow CFLAGS to contain arbitrary preprocessor commands like -includeColin Walters2013-03-061-0/+2
| | | | | | | | | Newer spidermonkey .pc file contains a -include argument, which g-ir-scanner doesn't understand. Rather than us attempting to replicate all of cpp's options, use wrapper arguments in Makefile.introspection to pass them through. https://bugzilla.gnome.org/show_bug.cgi?id=695182
* Revert "gi-r-scanner: add support for raw CFLAGS flags option"Colin Walters2013-03-051-1/+1
| | | | | | Doesn't work with arguments that have shell quotes. This reverts commit 95b03cf87efbd4fea4b7d55601c9752cefd29bfc.
* gi-r-scanner: add support for raw CFLAGS flags optionTim Lunn2013-03-061-1/+1
| | | | | | | | gi-r-scanner chokes when gir_CFLAGS have an '-include <header>' since this is not a recognised option. This commit adds a new --cflags option that passes cflags directly to the spawned gcc. https://bugzilla.gnome.org/show_bug.cgi?id=695182
* Makefile.introspection: Add gir dependency to exampleColin Walters2012-08-141-0/+1
|
* Makefile.introspection: allow buildir girs in subdirsMarc-Antoine Perennou2011-12-051-1/+2
| | | | | | | | | | | Formerly, trying to build gi/Foo-1.0.gir resulted in namespace being set to "gi/Foo" Trying to build g-i/Foo-1.0.gir was even setting it to "g" This fixes this behaviour by only considerating the filename without dirs. Btw, ensure that the directory exists Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com> https://bugzilla.gnome.org/show_bug.cgi?id=665276
* Makefile.introspection: Allow usage with --header-onlyColin Walters2011-10-191-1/+2
|
* Windows port: Work arount MSYS weirdness where it changes --libtool= command ↵Dieter Verfaillie2011-09-071-2/+6
| | | | | | | | | | | | line arguments. This continues to reuse the LIBTOOL variable from automake if it's set, but works around some MSYS weirdness: When running g-ir-scanner, MSYS changes a command-line argument --libtool="/bin/sh ../../libtool" into --libtool=c:/opt/msys/1.0/bin/libtool. So just use sh.exe without path because we already "know" where the libtool configure produced is. https://bugzilla.gnome.org/show_bug.cgi?id=620566
* Use INTROSPECTION_SCANNER_ENV in Makefile.introspectionJohan Dahlin2011-08-291-1/+3
|
* Bug 628594 — Handle slashes when building _gir_namePhilip Withnall2010-09-061-1/+1
| | | | | Convert slashes to underscores in _gir_name so that non-recursive builds can use Makefile.introspection. Closes: bgo#628594
* Makefile.introspection: Add _EXPORT_PACKAGES variable.Luca Bruno2010-08-281-0/+4
| | | | This new variable maps to --pkg-export.
* In verbose mode, print out the dump compilationColin Walters2010-07-071-4/+8
| | | | | | | | | | | | When debugging the dumper, it's extremely useful to be able to see the argument it's passing to the compiler/linker. This patch makes g-ir-scanner work the same way as libtool basically; we default to printing out stuff, and add a --quiet option. The Makefile.introspection handles passing --quiet automatically. https://bugzilla.gnome.org/show_bug.cgi?id=622751
* Move pkg-config calls before --library and --programColin Walters2010-06-251-2/+2
| | | | | | | We need our just-built library path to override what we have from pkg-config. https://bugzilla.gnome.org/show_bug.cgi?id=605156
* Makefile.introspection: add support for gir_LDFLAGSSteve Frécinaux2010-06-071-0/+2
| | | | | | | | | | This allows specifying LDFLAGS for the introspection scanner. LDFLAGS are currently just appended to the CFLAGS as the current scanner doesn't make the difference between both, but it looked wrong to include LDFLAGS in the middle of CFLAGS for g-ir-scanner. https://bugzilla.gnome.org/show_bug.cgi?id=620875
* Makefile.introspection: use $^, simplifying non-srcdir buildsDan Winship2010-05-201-3/+3
| | | | | | | | | | | | | | | | | | | In the .gir-building rule, use "$^" to refer to the source files, since that automatically looks in both $(srcdir) and $(builddir). This is particularly important since certain generated files will be in $(builddir) when building from git, but in $(srcdir) when building from tarballs If you were previously prefixing $(srcdir) to the Foo_gir_FILES members by hand, you should stop now. (Also, removed the dependencies on $(INTROSPECTION_SCANNER) and $(INTROSPECTION_COMPILER) for the .gir/.typelib rules, since the scanner one was broken anyway, and we don't have that kind of dependency for other rules (eg, making .o files depend on /usr/bin/gcc).) https://bugzilla.gnome.org/show_bug.cgi?id=616425
* [Makefile.introspection] Do not use _GIRDIRJohan Dahlin2010-05-171-3/+3
| | | | Instead use the path from configure in the example.
* Make sure the macros work without silent rulesJohan Dahlin2009-12-311-2/+4
| | | | | We should not require AM_DEFAULT_VERBOSITY to be present, workaround that fact
* Make compiler output with silent-rules prettierJohan Dahlin2009-12-301-2/+11
| | | | | This is only supported with automake 1.11 or newer, older versions should default to showing nothing for now.
* Do not require the precense of INTROSPECTION_GIRSJohan Dahlin2009-12-141-1/+0
| | | | | It's useful to be able to include the makefile without having introspection enabled.
* Move the functions out of the defineJohan Dahlin2009-12-141-22/+23
| | | | | As it breaks when including the makefile when using an absolute path.
* Add a Makefile.introspectionJohan Dahlin2009-12-141-0/+134
This will make it easier for third-party projects to use introspection by having easy make rules.
View Lorry Controller Status