Hi Fan,
Thanks for sharing. FYI, MinGW makefiles from latest master generate and
install "gdbus-codegen" correctly. You may want to take inspiration from
them if you plan to add gdbus-codegen generation for MSVC (don't know this
toolchain enough to do it myself).
I just suggested a little pa
Hi John,
(list people: I understand this is a rather old topic that was brought
up few months ago:) ).
I was poking around with the Python scripts for gdbus-codegen lately,
and I thought it might be good to let you know a few things about its
use on Windows, especially under Visual Studio builds
I would like to see that information - even if I have no instant use
for it - but I am pretty sure it will help a lot of people digging for
information.
Best
Bernhard
2013/2/19 John Emmas :
> On 4 Jan 2013, at 10:49, Matthew Brush wrote:
>
>>
>> From the last few messages on this thread, it kind
Hi John,
I'm sorry if this sounds a bit off-topic, but can you check your Visual
Studio 2005 build (if I recalled correctly, that's the version of Visual
Studio you are using) of
gspawn-win32-helper.exe/gspawn-win32-helper-console.exe whether programs
using them are able to complete successfu
On Feb 19, 2013, at 8:22 AM, John Emmas wrote:
> On 19 Feb 2013, at 15:37, Bernhard Schuster wrote:
>
>> I would like to see that information - even if I have no instant use
>> for it - but I am pretty sure it will help a lot of people digging for
>> information.
>>
>
> No problem. At the mo
On 19 Feb 2013, at 15:37, Bernhard Schuster wrote:
> I would like to see that information - even if I have no instant use
> for it - but I am pretty sure it will help a lot of people digging for
> information.
>
No problem. At the moment, I've made a couple of dozen changes in my efforts
to tr
On 4 Jan 2013, at 10:49, Matthew Brush wrote:
>
> From the last few messages on this thread, it kind of sounds like your module
> search path is not set up correctly, that is, Python doesn't know where to
> look to import your modules/packages (try "print(sys.path)" to see which
> paths I mean
On 13-01-04 02:13 AM, John Emmas wrote:
On 30 Dec 2012, at 16:36, John Ralls wrote:
Hmm. Your python doesn't seem to agree that codegen is a package, in spite of
being imported into gdbus-codegen.
On 30 Dec 2012, at 16:40, jose.ali...@gmail.com wrote:
I don't know if this is related, bu
On 30 Dec 2012, at 16:36, John Ralls wrote:
>
> Hmm. Your python doesn't seem to agree that codegen is a package, in spite of
> being imported into gdbus-codegen.
>
On 30 Dec 2012, at 16:40, jose.ali...@gmail.com wrote:
> I don't know if this is related, but It seems you are missing the empt
On Jan 1, 2013, at 8:11 PM, John Emmas wrote:
> On 1 Jan 2013, at 15:54, John Emmas wrote:
>
>>
>> If anyone has a flash of inspiration, please let me know.
>>
>
> I had a flash of inspiration myself...
>
>>
>> Traceback (most recent call last):
>> File
>> "F:/+GTK-SOURCES/gnu-win32/src
On 1 Jan 2013, at 15:54, John Emmas wrote:
>
> If anyone has a flash of inspiration, please let me know.
>
I had a flash of inspiration myself...
>
> Traceback (most recent call last):
> File
> "F:/+GTK-SOURCES/gnu-win32/src/glib/gio/gdbus-2.0/codegen/gdbus-codegen.in",
> line 39, in
>
On 30 Dec 2012, at 16:40, jose.ali...@gmail.com wrote:
> It seems you are missing the empty __init__.py in the codegen/ directory.
> This is a requirement for a directory so python may consider it as a package.
>
On 30 Dec 2012, at 16:36, John Ralls wrote:
> Hmm. Your python doesn't seem to a
On 31 Dec 2012, at 17:53, David Nečas wrote:
>
> This all goes to a strange direction.
>
> First, GRegistryBackend is not an enum, it is a subclass of
> GSettingsBackend. glib-mkenums will not generated
> g_registry_backend_get_type() for you.
>
> The get-type function g_registry_backend_get_t
On Mon, Dec 31, 2012 at 05:24:09PM +, John Emmas wrote:
> which should either be in gio/gioenums.h or alternatively,
> gio/gregistrysettingbackend.h. It's the absence of this enum that's
> causing 'g_registry_backend_get_type()' to not get auto-generated when
> glib-mkenums gets processed.
Th
I've come to the conclusion that gio has a missing set of enumerations of this
form:-
typedef enum {
G_REGISTRY_BACKEND_blah
G_REGISTRY_BACKEND_blah_blah
G_REGISTRY_BACKEND_blah_blah_blah
etc
} GRegistryBackend;
which should either be in gio/gioenums.h or alternatively,
Oh,
my bad choice of words...If the __init__.py is there and not empty, then
this should not be a problem in the import, python should recognize codegen
as a package. I didn't look, and I just wanted to point out that for a
directory to be considered a package, you need a __init__.py, which in mo
On Dec 30, 2012, at 8:40 AM, jose.ali...@gmail.com wrote:
> I don't know if this is related, but It seems you are missing the empty
> __init__.py in the codegen/ directory. This is a requirement for a directory
> so python may consider it as a package.
>
That would indeed cause the problem, b
I don't know if this is related, but It seems you are missing the empty
__init__.py in the codegen/ directory. This is a requirement for a
directory so python may consider it as a package.
On Sun, Dec 30, 2012 at 5:36 PM, John Ralls wrote:
>
> On Dec 30, 2012, at 3:47 AM, John Emmas wrote:
>
On Dec 30, 2012, at 3:47 AM, John Emmas wrote:
> On 29 Dec 2012, at 21:12, John Emmas wrote:
>
>>
>> On 29 Dec 2012, at 16:41, John Ralls wrote:
>>
>>>
>>> That's because gio/gdbus-2.0/codegen/config.py doesn't exist, but
>>> config.py.in does -- another file that needs to have its @variabl
On 29 Dec 2012, at 21:12, John Emmas wrote:
>
> On 29 Dec 2012, at 16:41, John Ralls wrote:
>
>>
>> That's because gio/gdbus-2.0/codegen/config.py doesn't exist, but
>> config.py.in does -- another file that needs to have its @variables@
>> substituted -- in this case @datarootdir@, @prefix@,
On 29 Dec 2012, at 16:41, John Ralls wrote:
>
> That's because gio/gdbus-2.0/codegen/config.py doesn't exist, but
> config.py.in does -- another file that needs to have its @variables@
> substituted -- in this case @datarootdir@, @prefix@, and @VERSION@.
>
> This one *is* done by configure, w
On Dec 29, 2012, at 7:20 AM, John Emmas wrote:
> On 29 Dec 2012, at 09:55, David Nečas wrote:
>
>>
>> Anything ending with .in is usually processed by configure
>> (config.status) which you obviously don't have so you must replace
>> @VARIABLE@s with the corresponding values using whatever you
On 29 Dec 2012, at 09:55, David Nečas wrote:
>
> Anything ending with .in is usually processed by configure
> (config.status) which you obviously don't have so you must replace
> @VARIABLE@s with the corresponding values using whatever you have. But
> the only two variables present there are unu
On Sat, Dec 29, 2012 at 07:13:56AM +, John Emmas wrote:
> 2) Along a similar vein, it looks like I need to process the module
> 'gio/gdbus-2.0/codegen/gdbus-codegen.in' but I don't know what program
> / script I need for processing it.
Anything ending with .in is usually processed by configur
Thanks for everyone's help with this. The problem with glib-mkenums did indeed
turn out to be a missing list of header files. Now that I've added that,
things are getting a lot further. MSVC users might be interested to hear that
I'm now tantalizingly close to being able to build glib using o
Hello John,
[snip]At least it seems so, if this web page is to be believed:-
http://www.gtk.org/download/win32.php
You might want to look at this page instead:
http://www.gtk.org/download/linux.php, as the win32 page you have
mentioned is unfortunately out of date. The latest stable tarball i
On Wed, 26 Dec 2012 12:12:08 -0800, John Ralls wrote:
> perl -e 'print(join("\n", @ARGV));' foo bar
This won't work on Windows - the quoting rules are more complicated.
Either of the following should work:
perl -e "print(join("""\n""", @ARGV));" foo bar
perl -e "print(join(qq(\n), @ARGV));" foo
Hi Fen,
I'm sure you're right about the tarball VCPROJ files being up-to-date but the
stable tarballs themselves are a long way out of date. At least it seems so,
if this web page is to be believed:-
http://www.gtk.org/download/win32.php
According to the information there, version 2.28.8 is t
於 2012/12/27 下午 05:15, John Emmas 提到:
> Thanks for the reply, Fen.
>
> As it happens, it is VS2005 that I'm using but I'm pretty sure that
> the other VS projects are out of date too. I'm using the versions that
> are here:-
Hello John,
Ah, the VS 2005 projects are the reason why it seemed to you
At 27.12.2012 11:56, John Emmas wrote:
[...]
Knowing that I'd at least managed to get _something_ working, I then tried
running 'glib-mkenums' again - this time using Perl from MinGW/MSYS.
However, that essentially gave me the same error that I reported in the
first place:-
/* Generated data (b
On 27 Dec 2012, at 10:05, wrote:
>
> I just tried on my Windows machine in a regular "cmd.exe" (command
> window). You need to change the double quotes. Windows be damned!
>
> I always forget to translate single quote to double quote. Windows
> cmd.exe gives some very strange error messages
On 26 Dec 2012, at 20:12, John Ralls wrote:
>
> If you run:
>
> perl -e 'print(join("\n", @ARGV));' foo bar
>
> you should get the output
>
> foo
> bar
>
Hi John, I discovered something quite interesting this morning... I have 5
different versions of Perl installed (on different machines)
example.
Hope this helps
With blessings
- 原始郵件 -
寄件者: John Emmas
寄件日期: 2012/12/27 02:19
收件者: gtk-devel-list@gnome.org
主旨: glib-mkenums in glib 2
As many of you will know, GTK's MSVC project files have gotten quite a long way
out of date now (presumably since Tor's departure, w
On 26 Dec 2012, at 20:12, John Ralls wrote:
>
> If you run:
>
> perl -e 'print(join("\n", @ARGV));' foo bar
>
> you should get the output
>
> foo
> bar
>
> Do you?
>
No John, in fact I got this output
Can't find string terminator "'" anywhere before EOF at -e line 1.
To be certain, I
On Dec 26, 2012, at 11:48 AM, John Emmas wrote:
> On 26 Dec 2012, at 19:20, John Ralls wrote:
>
>>
>> ARGV should be a hint: It means the same thing in perl as it does in C. It
>> seems that glib-mkenums either isn't getting an @ARGV or it's somehow
>> getting cleared before that line.
>>
>
On 26 Dec 2012, at 19:20, John Ralls wrote:
>
> ARGV should be a hint: It means the same thing in perl as it does in C. It
> seems that glib-mkenums either isn't getting an @ARGV or it's somehow getting
> cleared before that line.
>
Thanks John. I think the fact that ARGV[0] is involved migh
On Dec 26, 2012, at 10:18 AM, John Emmas wrote:
> As many of you will know, GTK's MSVC project files have gotten quite a long
> way out of date now (presumably since Tor's departure, which was a great
> pity). I'm trying to bring mine up-to-date so that they'll build from the
> latest GIT so
As many of you will know, GTK's MSVC project files have gotten quite a long way
out of date now (presumably since Tor's departure, which was a great pity).
I'm trying to bring mine up-to-date so that they'll build from the latest GIT
sources. I'm starting with glib which is currently at versio
38 matches
Mail list logo
