The confusion is arising from the fact that the working code is in 2.48
https://github.com/GNOME/glib/blob/glib-2-48/gobject/gobject.c#L398-L406
The non-working code is in master.
On Wed, Aug 3, 2016 at 11:35 AM, John Emmas wrote:
> On 03/08/2016 18:46, Emmanuele Bassi wrote:
>>
>> This is like
I don't believe you're allowed to legally use macros inside a macro
expansion -
https://stackoverflow.com/questions/19111383/ifdef-inside-a-macro-call-works-with-gcc-but-not-with-msvc
On Wed, Aug 3, 2016 at 10:46 AM, Emmanuele Bassi wrote:
> Hi;
>
> On 3 August 2016 at 18:36, John Emmas wrote:
https://github.com/GNOME/glib/blob/236e804/glib/gutils.h#L69
Presumably this is not being included by gtypes.h
inline in C is a C99 feature, which is why older VS doesn't support
it. VS2015 does.
-Arnav
On Mon, Nov 2, 2015 at 2:27 PM, Emmanuele Bassi wrote:
> Hi;
>
> On 2 November 2015 at 20:10
sue in gdk-pixbuf). Fan: please take a look at both
when you can. Apart from these two I didn't have any problems building
GTK2 with VS2015.
-Arnav
On Sun, Oct 11, 2015 at 1:35 AM, Ignacio Casal Quinteiro
wrote:
> Hi Arnavion,
>
> is this problem just specific to VS 2015? It seems weird t
f.c;h=968835a1e7d5a704ae5a330ecda091b78851f73c;hp=8377d31eb591687186815e1de5cf973aac465120;hb=ba739e5686c1488280341451c3eb01a8f7b0aaa1;hpb=8c1ff97529b4f5b6462f1be302cc526ccb1960a1
-Arnav
On Sat, Oct 10, 2015 at 9:08 PM, LRN wrote:
> On 11.10.2015 7:00, Arnavion wrote:
>> Hi Fan,
>&g
Hi Fan,
In your commit 53d487e31bc41cca9bca147e02e81b69e404fe07 to glib you
enabled glib to use VS2015's snprintf. Did you confirm it works?
I'm updating our gtk-win32 repo to use glib 2.46.0 (from 2.44.1) and
ATK fails to build - it runs glib-genmarshal as part of build when
calling g_strdup_pri
Chun-Wei: I looked at ATK 2.14 sources and didn't find any variables
exported with ATK_AVAILABLE_IN_ALL, only functions. So it would seem ATK
has no problems by virtue of not actually exporting any data.
I then looked at Glib 2.42 sources and found quite a few exported variables
but they are all e
(I haven't looked at the headers in question myself).
If I'm understanding the situation correctly, you're building a binary
that includes an atk(mm) header that has some functions marked with
dllexport (from the POV of the compiler when it's compiling your
code).
>Technically though, I don't kn
d earlier, why not simply require all
updates to the makefiles be mirrored in the vcxproj files too? Is that
unenforcable?
-Arnav
On Wed, Nov 13, 2013 at 8:30 PM, Fan Chun-wei wrote:
> Hello Arnavion,
>
>> Speaking as a consumer of the MSVC project files, is it too much to
>> ask f
Hi,
Speaking as a consumer of the MSVC project files, is it too much to
ask for contributors to maintain the project files statically and
update them whenever they update the makefiles? There is no need to do
this in VS or even Windows; the vcxproj file is easy to maintain via a
text editor.
It s
ice part about these builds, is that they’re all pretty atomic –
> dependencies are brought in using the packages and so anyone can generally
> rebuild an individual package.
>
> ** **
>
> Garrett
>
>
>
> ** **
>
> *From:* Arnavion [mailto:arnav...@gmail.com]
> *Sent:* Wednes
Hi Garrett,
You mentioned that you have done work to provide builds of common
open-source libraries. Can you provide more information on this?
- Do you mean that these builds are done using MSVC?
- Does this include any libraries that GTK depends on?
I am curious to see if any of the work we do o
c).
>
> I would like to see:
>
> - Patches upstreamed in all cases where possible (like the ones you
> mention Arnavion).
>
These patches usually do make it upstream. A quick glance through the bugs
from which we got some of our patches shows many of them resolved and
fixed. (
Hello,
I am a fellow Hexchat dev with bviktor, and I thought I'd just provide a
few clarifications:-
1. The instructions to build GTK+ on gtk.hexchat.org are for building using
Visual Studio 2012, as opposed to Tarnkyo's work that uses MinGW. We use VS
to build our entire stack (GTK and its deps,
14 matches
Mail list logo
