meson/test cases/frameworks/22 gir link order/meson-sample.h

#ifndef MESON_SAMPLE_H
#define MESON_SAMPLE_H

#include <glib-object.h>

G_BEGIN_DECLS

#define MESON_TYPE_SAMPLE (meson_sample_get_type())

G_DECLARE_FINAL_TYPE (MesonSample, meson_sample, MESON, SAMPLE, GObject)

MesonSample *meson_sample_new           (void);
void         meson_sample_print_message (MesonSample *self);

G_END_DECLS

#endif /* MESON_SAMPLE_H */
gnome: Distinguish between internal and external linker flags When an older version of the library being built is installed in the same prefix as external dependencies, we have to be careful to construct the linker or compiler command line. If a -L flag from external dependencoes comes before a -L flag pointing to builddir, it is possible for the linker to load older libraries from the installation prefix instead of the newly built ones, which is likely to cause undefined reference error. Since the order of dependencies is not significant, we cannot expect internal dependencies to appear before external dependencies when recursively iterating the list of dependencies. To make it harder to make mistakes, linker flags come from internal and external dependencies are now stored in different order sets. Code using _get_dependencies_flags are expected to follow the order when constructing linker command line: 1. Internal linker flags 2. LDFLAGS set by users 3. External linker flags It is similar to what automake and libtool do for autotools projects. 7 years ago			`#ifndef MESON_SAMPLE_H`
			`#define MESON_SAMPLE_H`

			`#include <glib-object.h>`

			`G_BEGIN_DECLS`

			`#define MESON_TYPE_SAMPLE (meson_sample_get_type())`

			`G_DECLARE_FINAL_TYPE (MesonSample, meson_sample, MESON, SAMPLE, GObject)`

			`MesonSample *meson_sample_new (void);`
			`void meson_sample_print_message (MesonSample *self);`

			`G_END_DECLS`

			`#endif /* MESON_SAMPLE_H */`