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
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
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 john...@tiscali.co.uk:
On 4 Jan 2013, at 10:49, Matthew Brush wrote:
From the last few messages on this
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 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 track
On Feb 19, 2013, at 8:22 AM, John Emmas john...@tiscali.co.uk 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.
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
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 empty
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,
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
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 module
On Jan 1, 2013, at 8:11 PM, John Emmas john...@tiscali.co.uk 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
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,
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.
This
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_type()
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@, and
On Dec 30, 2012, at 3:47 AM, John Emmas john...@tiscali.co.uk 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
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 jra...@ceridwen.us wrote:
On Dec 30, 2012, at 3:47 AM, John
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, but
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
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 configure
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 unused
On Dec 29, 2012, at 7:20 AM, John Emmas john...@tiscali.co.uk 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
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, which
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
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) - namely:-
On 27 Dec 2012, at 10:05, kevin.a...@ubs.com 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
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
於 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 the
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
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 bar
Note
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
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
On Dec 26, 2012, at 10:18 AM, John Emmas john...@tiscali.co.uk 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
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 might be
On Dec 26, 2012, at 11:48 AM, John Emmas john...@tiscali.co.uk 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
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 copied and
, for 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, which
38 matches
Mail list logo
