Re: Qt Compile Flags (Was: Compiling Without Installing)
|
View:
New views
14 Messages
—
Rating Filter:
Alert me
|
 |
|
|
|
Re: Qt Compile Flags (Was: Compiling Without Installing)
by Jonathan Yu
::
Rate this Message:
Eric, et al:
Sune (pusling) on IRC mentioned this to me. It looks as if it does exactly what we need. I'll work on writing a patch to our Build.PL/etc to get it to configure the flags properly :-) I want also to make sure users can override it, in case pkg-config isn't installed. So perhaps we can offer an environment variable that will determine the paths. I'll need to hack on that; when I have it relatively tested I'll commit something that we can test :-) (Something I also want to work on -- perhaps I can take a branch of the trunk -- is separating the qtsmoke stuff from the actual Perl binding source) Cheers, Jonathan On Wed, Jun 3, 2009 at 2:25 PM, Eric Wilhelm <ewilhelm@...> wrote: > # from Jonathan Yu > # on Monday 01 June 2009 15:13: > >>What I'd really like to see is a command like pkg-config for Qt. How >>hasn't this come up before? > > My qt-4.5.1 install has a full complement of .pc files. > > e.g. > pkg-config --libs QtGui > > Does this not do what we need? > > See also ExtUtils::PkgConfig, though it doesn't seem to be super > rigorous about checking the exit code of backticks, it does at least > provide some level of abstraction. > > --Eric > -- > I arise in the morning torn between a desire to improve the world and a > desire to enjoy the world. This makes it hard to plan the day. > --E.B. White > --------------------------------------------------- > http://scratchcomputing.com > --------------------------------------------------- > Kde-perl mailing list Kde-perl@... https://mail.kde.org/mailman/listinfo/kde-perl |
|
|
Re: Qt Compile Flags (Was: Compiling Without Installing)
by Chris Burel
::
Rate this Message:
Yes, pkg-config will work for us for Qt, but not for Smoke. Last time
I looked, kde-bindings doesn't ship with .pc files. I checked <kdeprefix>/lib/pkgconfig, and saw none related to smoke. Perhaps that'd be useful for smoke to include? Jonathan, I saw a post from you earlier about restructuring the directory layout of the bindings to accommodate using the Makefile.PL/ExtUtils::MakeMaker build method. Currently we have this PerlQt4 |-smoke | \-qt | \-... \-perl \-bindings files You wanted to make it PerlQt4 \-perl |-smoke | \-qt | \-... \-bindings files Don't you think we can make it work as it is? If there's a Makefile.PL at the top level, and a Makefile.PL in the smoke directory that builds smoke for us, and a Makefile.PL in the perl dir that builds the bindings, wouldn't that work? Then we could keep our structure similar to that of kde-bindings, so it's easy for us to commit there when we're ready, and will integrate nicely with their CMake build system. On Wed, Jun 3, 2009 at 11:29 AM, Jonathan Yu <jonathan.i.yu@...> wrote: > Eric, et al: > > Sune (pusling) on IRC mentioned this to me. > > It looks as if it does exactly what we need. I'll work on writing a > patch to our Build.PL/etc to get it to configure the flags properly > :-) > > I want also to make sure users can override it, in case pkg-config > isn't installed. So perhaps we can offer an environment variable that > will determine the paths. I'll need to hack on that; when I have it > relatively tested I'll commit something that we can test :-) > > (Something I also want to work on -- perhaps I can take a branch of > the trunk -- is separating the qtsmoke stuff from the actual Perl > binding source) > > Cheers, > > Jonathan > > On Wed, Jun 3, 2009 at 2:25 PM, Eric Wilhelm > <ewilhelm@...> wrote: >> # from Jonathan Yu >> # on Monday 01 June 2009 15:13: >> >>>What I'd really like to see is a command like pkg-config for Qt. How >>>hasn't this come up before? >> >> My qt-4.5.1 install has a full complement of .pc files. >> >> e.g. >> pkg-config --libs QtGui >> >> Does this not do what we need? >> >> See also ExtUtils::PkgConfig, though it doesn't seem to be super >> rigorous about checking the exit code of backticks, it does at least >> provide some level of abstraction. >> >> --Eric >> -- >> I arise in the morning torn between a desire to improve the world and a >> desire to enjoy the world. This makes it hard to plan the day. >> --E.B. White >> --------------------------------------------------- >> http://scratchcomputing.com >> --------------------------------------------------- >> > Kde-perl mailing list Kde-perl@... https://mail.kde.org/mailman/listinfo/kde-perl |
|
|
Re: Qt Compile Flags (Was: Compiling Without Installing)
by Jonathan Yu
::
Rate this Message:
Chris:
Hm. I suppose that the entire directory tree should be kept as-is, since having CMake build everything is what other bindings do (previous to this message I was unaware of that design consideration). On the other hand, the other stuff isn't really all that important from a Perl standpoint. What I want to do, then, is push just the perl folder itself as its own distribution to CPAN. Then nothing in our repository needs to be moved. (Some minor adjustments may need to be made, but overall the package structure should be mostly intact) I'll work over the next couple days with getting the Makefile.PL to detect if smoke is installed and die otherwise (since this is something CMake takes care of, right?). Then it can be uploaded to CPAN as-is. I'm currently looking into extending App::Info to help us find Qt stuff (see App::Info on CPAN). Oh, one thing I'd like to get your opinion on, though: do you mind if I upgrade the build over to Build.PL? What impact does that have on our package, and on how CMake builds it? I imagine it'd just be a simple change: perl Build.PL; perl Build test (rather than perl Makefile.PL; make). However, since it would be using 'perl Build' rather than make, I'm not sure how it'd integrate with CMake; probably not as nicely. The reason I want to switch it over is because Build.PL is much more capable of handling complex tasks than Makefile.PL. Things like recommended dependencies, and in general the syntax is just more maintainable to me. I could arrange for a compatibility Makefile.PL to be available too (using Module::Build::Compat). Cheers, Jonathan On Wed, Jun 3, 2009 at 3:43 PM, Chris Burel <chrisburel@...> wrote: > Yes, pkg-config will work for us for Qt, but not for Smoke. Last time > I looked, kde-bindings doesn't ship with .pc files. I checked > <kdeprefix>/lib/pkgconfig, and saw none related to smoke. Perhaps > that'd be useful for smoke to include? > > Jonathan, I saw a post from you earlier about restructuring the > directory layout of the bindings to accommodate using the > Makefile.PL/ExtUtils::MakeMaker build method. Currently we have this > PerlQt4 > |-smoke > | \-qt > | \-... > \-perl > \-bindings files > > You wanted to make it > PerlQt4 > \-perl > |-smoke > | \-qt > | \-... > \-bindings files > > Don't you think we can make it work as it is? If there's a > Makefile.PL at the top level, and a Makefile.PL in the smoke directory > that builds smoke for us, and a Makefile.PL in the perl dir that > builds the bindings, wouldn't that work? Then we could keep our > structure similar to that of kde-bindings, so it's easy for us to > commit there when we're ready, and will integrate nicely with their > CMake build system. > > On Wed, Jun 3, 2009 at 11:29 AM, Jonathan Yu <jonathan.i.yu@...> wrote: >> Eric, et al: >> >> Sune (pusling) on IRC mentioned this to me. >> >> It looks as if it does exactly what we need. I'll work on writing a >> patch to our Build.PL/etc to get it to configure the flags properly >> :-) >> >> I want also to make sure users can override it, in case pkg-config >> isn't installed. So perhaps we can offer an environment variable that >> will determine the paths. I'll need to hack on that; when I have it >> relatively tested I'll commit something that we can test :-) >> >> (Something I also want to work on -- perhaps I can take a branch of >> the trunk -- is separating the qtsmoke stuff from the actual Perl >> binding source) >> >> Cheers, >> >> Jonathan >> >> On Wed, Jun 3, 2009 at 2:25 PM, Eric Wilhelm >> <ewilhelm@...> wrote: >>> # from Jonathan Yu >>> # on Monday 01 June 2009 15:13: >>> >>>>What I'd really like to see is a command like pkg-config for Qt. How >>>>hasn't this come up before? >>> >>> My qt-4.5.1 install has a full complement of .pc files. >>> >>> e.g. >>> pkg-config --libs QtGui >>> >>> Does this not do what we need? >>> >>> See also ExtUtils::PkgConfig, though it doesn't seem to be super >>> rigorous about checking the exit code of backticks, it does at least >>> provide some level of abstraction. >>> >>> --Eric >>> -- >>> I arise in the morning torn between a desire to improve the world and a >>> desire to enjoy the world. This makes it hard to plan the day. >>> --E.B. White >>> --------------------------------------------------- >>> http://scratchcomputing.com >>> --------------------------------------------------- >>> >> > Kde-perl mailing list Kde-perl@... https://mail.kde.org/mailman/listinfo/kde-perl |
|
|
Re: Qt Compile Flags (Was: Compiling Without Installing)
by Eric Wilhelm-5
::
Rate this Message:
# from Jonathan Yu
# on Wednesday 03 June 2009 13:00: >I'll work over the next couple days with getting the Makefile.PL to >detect if smoke is installed and die otherwise (since this is >something CMake takes care of, right?). Then it can be uploaded to >CPAN as-is. I'm currently looking into extending App::Info to help us >find Qt stuff (see App::Info on CPAN). One idea here is to have an Alien::Smoke and/or Alien::Qt packages (ala Alien::wxWidgets) which allows you to break those dependencies into separate dists -- so you can automatically install everything with the cpan client, but you can also quickly upgrade the Qt4 dist for perl-only changes. >do you mind if I upgrade the build over to Build.PL? >...is much more capable of handling complex tasks than Makefile.PL I'll second that. (Disclaimer: I'm the Module::Build maintainer.) --Eric -- The opinions expressed in this e-mail were randomly generated by the computer and do not necessarily reflect the views of its owner. --Management --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- _______________________________________________ Kde-perl mailing list Kde-perl@... https://mail.kde.org/mailman/listinfo/kde-perl |
|
|
Re: Qt Compile Flags (Was: Compiling Without Installing)
by Jonathan Yu
::
Rate this Message:
Eric:
Actually, an Alien:: package (or several) seems like a good idea. One thing I'm not sure about, though, is whether Alien:: packages should be designed to work with normal user accounts (ie non-root CPAN installs). I'm not even sure what package to use as a reference for this -- I did look at Alien::Judy which is a simple enough package that I can sort of grasp what is happening. Moreover, I'd want to reduce the build dependencies if possible, especially in the case where there are modules already installed on the system. I'd like it if users didn't have to download the Alien:: stuff if App::Info detects that it's already installed (App::Info would be a build dependency, rather than a full out dependency). This is particularly useful for people that are on systems like, say, Debian.. where the trick is to find out if there is a system-installed version, or ask the user otherwise. Perhaps the Alien package could be used as a convenience, more like: 1. Download App::Info for Smoke 2. Check if libsmokeqt is installed 3. If it is, then use it; otherwise: 4. Prompt the user to install it, ask if it's okay, etc (maybe EUMM's prompt subroutine can be used for this) 5. Install Alien::Smoke etc via CPAN If the lib is already installed, then (as detected by App::Info), then you wouldn't need to install the Alien version via CPAN. Thus Alien::Smoke wouldn't be a direct dependency. Cheers, Jonathan On Wed, Jun 3, 2009 at 4:07 PM, Eric Wilhelm <ewilhelm@...> wrote: > # from Jonathan Yu > # on Wednesday 03 June 2009 13:00: > >>I'll work over the next couple days with getting the Makefile.PL to >>detect if smoke is installed and die otherwise (since this is >>something CMake takes care of, right?). Then it can be uploaded to >>CPAN as-is. I'm currently looking into extending App::Info to help us >>find Qt stuff (see App::Info on CPAN). > > One idea here is to have an Alien::Smoke and/or Alien::Qt packages (ala > Alien::wxWidgets) which allows you to break those dependencies into > separate dists -- so you can automatically install everything with the > cpan client, but you can also quickly upgrade the Qt4 dist for > perl-only changes. > >>do you mind if I upgrade the build over to Build.PL? >>...is much more capable of handling complex tasks than Makefile.PL > > I'll second that. (Disclaimer: I'm the Module::Build maintainer.) > > --Eric > -- > The opinions expressed in this e-mail were randomly generated by > the computer and do not necessarily reflect the views of its owner. > --Management > --------------------------------------------------- > http://scratchcomputing.com > --------------------------------------------------- > _______________________________________________ > Kde-perl mailing list > Kde-perl@... > https://mail.kde.org/mailman/listinfo/kde-perl > Kde-perl mailing list Kde-perl@... https://mail.kde.org/mailman/listinfo/kde-perl |
|
|
Re: Qt Compile Flags (Was: Compiling Without Installing)
by Chris Burel
::
Rate this Message:
I used the Makefile.PL because that's what
h2xs -A -n Qt gave me. It compiled what I needed, so all was good. If you guys think we should use Module::Build, and want to convert over, be my guest. It also sounds like a good idea to package smokeqt as an Alien::SmokeQt package. Remember that there are Smoke objects for different parts of Qt, KDE, Phonon, etc, that are all separate. For instance, qtuitools, qt, and qtscript all have separate smoke objects. So we'd want the module called Alien::SmokeQt, so that in the future we can have Alien::SmokeQtUiTools, Alien::SmokeQtScript, etc. I'd vote for Alien::SmokeQt over Alien::QtSmoke because the library that gets built is called libsmokeqt, not libqtsmoke. I don't see why you wouldn't be able to tell the Alien::SmokeQt package to install to your home directory, and then have PerlQt link to it from there. Why would normal user account installs be a problem? On Wed, Jun 3, 2009 at 1:36 PM, Jonathan Yu <jonathan.i.yu@...> wrote: > Eric: > > Actually, an Alien:: package (or several) seems like a good idea. > > One thing I'm not sure about, though, is whether Alien:: packages > should be designed to work with normal user accounts (ie non-root CPAN > installs). I'm not even sure what package to use as a reference for > this -- I did look at Alien::Judy which is a simple enough package > that I can sort of grasp what is happening. > > Moreover, I'd want to reduce the build dependencies if possible, > especially in the case where there are modules already installed on > the system. I'd like it if users didn't have to download the Alien:: > stuff if App::Info detects that it's already installed (App::Info > would be a build dependency, rather than a full out dependency). > > This is particularly useful for people that are on systems like, say, > Debian.. where the trick is to find out if there is a system-installed > version, or ask the user otherwise. Perhaps the Alien package could be > used as a convenience, more like: > > 1. Download App::Info for Smoke > 2. Check if libsmokeqt is installed > 3. If it is, then use it; otherwise: > 4. Prompt the user to install it, ask if it's okay, etc (maybe EUMM's > prompt subroutine can be used for this) > 5. Install Alien::Smoke etc via CPAN > > If the lib is already installed, then (as detected by App::Info), then > you wouldn't need to install the Alien version via CPAN. Thus > Alien::Smoke wouldn't be a direct dependency. > > Cheers, > > Jonathan > > On Wed, Jun 3, 2009 at 4:07 PM, Eric Wilhelm > <ewilhelm@...> wrote: >> # from Jonathan Yu >> # on Wednesday 03 June 2009 13:00: >> >>>I'll work over the next couple days with getting the Makefile.PL to >>>detect if smoke is installed and die otherwise (since this is >>>something CMake takes care of, right?). Then it can be uploaded to >>>CPAN as-is. I'm currently looking into extending App::Info to help us >>>find Qt stuff (see App::Info on CPAN). >> >> One idea here is to have an Alien::Smoke and/or Alien::Qt packages (ala >> Alien::wxWidgets) which allows you to break those dependencies into >> separate dists -- so you can automatically install everything with the >> cpan client, but you can also quickly upgrade the Qt4 dist for >> perl-only changes. >> >>>do you mind if I upgrade the build over to Build.PL? >>>...is much more capable of handling complex tasks than Makefile.PL >> >> I'll second that. (Disclaimer: I'm the Module::Build maintainer.) >> >> --Eric >> -- >> The opinions expressed in this e-mail were randomly generated by >> the computer and do not necessarily reflect the views of its owner. >> --Management >> --------------------------------------------------- >> http://scratchcomputing.com >> --------------------------------------------------- >> _______________________________________________ >> Kde-perl mailing list >> Kde-perl@... >> https://mail.kde.org/mailman/listinfo/kde-perl >> > _______________________________________________ > Kde-perl mailing list > Kde-perl@... > https://mail.kde.org/mailman/listinfo/kde-perl > Kde-perl mailing list Kde-perl@... https://mail.kde.org/mailman/listinfo/kde-perl |
|
|
Re: Alien:: package (was: Qt Compile Flags)
by Eric Wilhelm-5
::
Rate this Message:
# from Jonathan Yu
# on Wednesday 03 June 2009 13:36: >Moreover, I'd want to reduce the build dependencies if possible, >especially in the case where there are modules already installed on >the system. I'd like it if users didn't have to download the Alien:: >stuff if App::Info detects that it's already installed (App::Info >would be a build dependency, rather than a full out dependency). > >1. Download App::Info for Smoke >2. Check if libsmokeqt is installed >3. If it is, then use it; otherwise: >4. Prompt the user to install it, ask if it's okay, etc >5. Install Alien::Smoke etc via CPAN > >If the lib is already installed, then (as detected by App::Info), then >you wouldn't need to install the Alien version via CPAN. Thus >Alien::Smoke wouldn't be a direct dependency. I get what you're saying, but I think it would be simpler to maintain if Alien::SmokeQt is a static dependency which itself deals with the prodding and poking and prompting. See Alien::wxWidgets for example: 1. users says `cpan Wx` 2. cpan gets Wx-$latest.tar.gz, unpacks it, runs Makefile.PL 3. Wx requires Alien::wxWidgets > $some_version 4. cpan gets Alien-wxWidgets-$latest.tar.gz, unpacks it, runs Build.PL 5. Build.PL pokes around your system looking for a wx a. finds one, notes that location b. doesn't find one, prompts (defaults to ok) * downloads a tarball from sourceforge or whatever * unpacks, runs ./configure, make 6. ./Build install puts @stuff in your @INC Now, if your situation was case 5a (say, debian unstable), @stuff is just an Alien/wxWidgets.pm (and one other .pm). If 5b, @stuff also includes e.g. a gtk_2_8_8_uni/ directory with the lib/libwx_*.so and such files in it. The upshot of all of this is that no matter whether wx and/or Alien::wxWidgets was a debian package or installed on-the-fly, this "just works" perl -MAlien::wxWidgets -E 'say Alien::wxWidgets->version' And then the installer for the Wx dist just uses methods like Alien::wxWidgets->shared_libraries() to build itself. Of course, now that I look at App::Info, I see that it's basically that same kind of thing -- but Alien::wxWidgets predates it. The main difference seems to be that the presence of Alien::wxWidgets asserts that wxWidgets is installed (also see Alien::SVN.) So, how about making Alien::SmokeQt a subclass of App::Info? (or something like that -- bin_dir() and executable() won't really mean that much, but App::Info::Lib::Expat seems to be something of a precedent.) --Eric -- "Beware of bugs in the above code; I have only proved it correct, not tried it." --Donald Knuth --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- _______________________________________________ Kde-perl mailing list Kde-perl@... https://mail.kde.org/mailman/listinfo/kde-perl |
|
|
Re: Qt Compile Flags (Was: Compiling Without Installing)
by Jonathan Yu
::
Rate this Message:
Chris:
I don't think normal installs are a problem, per se, I just have no experience setting up that sort of thing. It's easier to find things when they're system-installed -- you can check in the usual library paths. However, when they're installed in the user directory, they can really be anywhere. So the App::Info instance would need to be able to account for that. Just adds a bit of extra complexity, and I'm not sure how the other modules do that sort of thing. Anyway, I think all of this is nice to have discussed up front, but it should be put on the back burner for now. Right now the big push is fixing that nasty issue with the segfaults, so I'll fix my module, finish compiling and hack on that. :-) Cheers, Jonathan On Wed, Jun 3, 2009 at 4:54 PM, Chris Burel <chrisburel@...> wrote: > I used the Makefile.PL because that's what > h2xs -A -n Qt > gave me. It compiled what I needed, so all was good. If you guys > think we should use Module::Build, and want to convert over, be my > guest. > It also sounds like a good idea to package smokeqt as an > Alien::SmokeQt package. Remember that there are Smoke objects for > different parts of Qt, KDE, Phonon, etc, that are all separate. For > instance, qtuitools, qt, and qtscript all have separate smoke objects. > So we'd want the module called Alien::SmokeQt, so that in the future > we can have Alien::SmokeQtUiTools, Alien::SmokeQtScript, etc. I'd > vote for Alien::SmokeQt over Alien::QtSmoke because the library that > gets built is called libsmokeqt, not libqtsmoke. > > I don't see why you wouldn't be able to tell the Alien::SmokeQt > package to install to your home directory, and then have PerlQt link > to it from there. Why would normal user account installs be a > problem? > > On Wed, Jun 3, 2009 at 1:36 PM, Jonathan Yu <jonathan.i.yu@...> wrote: >> Eric: >> >> Actually, an Alien:: package (or several) seems like a good idea. >> >> One thing I'm not sure about, though, is whether Alien:: packages >> should be designed to work with normal user accounts (ie non-root CPAN >> installs). I'm not even sure what package to use as a reference for >> this -- I did look at Alien::Judy which is a simple enough package >> that I can sort of grasp what is happening. >> >> Moreover, I'd want to reduce the build dependencies if possible, >> especially in the case where there are modules already installed on >> the system. I'd like it if users didn't have to download the Alien:: >> stuff if App::Info detects that it's already installed (App::Info >> would be a build dependency, rather than a full out dependency). >> >> This is particularly useful for people that are on systems like, say, >> Debian.. where the trick is to find out if there is a system-installed >> version, or ask the user otherwise. Perhaps the Alien package could be >> used as a convenience, more like: >> >> 1. Download App::Info for Smoke >> 2. Check if libsmokeqt is installed >> 3. If it is, then use it; otherwise: >> 4. Prompt the user to install it, ask if it's okay, etc (maybe EUMM's >> prompt subroutine can be used for this) >> 5. Install Alien::Smoke etc via CPAN >> >> If the lib is already installed, then (as detected by App::Info), then >> you wouldn't need to install the Alien version via CPAN. Thus >> Alien::Smoke wouldn't be a direct dependency. >> >> Cheers, >> >> Jonathan >> >> On Wed, Jun 3, 2009 at 4:07 PM, Eric Wilhelm >> <ewilhelm@...> wrote: >>> # from Jonathan Yu >>> # on Wednesday 03 June 2009 13:00: >>> >>>>I'll work over the next couple days with getting the Makefile.PL to >>>>detect if smoke is installed and die otherwise (since this is >>>>something CMake takes care of, right?). Then it can be uploaded to >>>>CPAN as-is. I'm currently looking into extending App::Info to help us >>>>find Qt stuff (see App::Info on CPAN). >>> >>> One idea here is to have an Alien::Smoke and/or Alien::Qt packages (ala >>> Alien::wxWidgets) which allows you to break those dependencies into >>> separate dists -- so you can automatically install everything with the >>> cpan client, but you can also quickly upgrade the Qt4 dist for >>> perl-only changes. >>> >>>>do you mind if I upgrade the build over to Build.PL? >>>>...is much more capable of handling complex tasks than Makefile.PL >>> >>> I'll second that. (Disclaimer: I'm the Module::Build maintainer.) >>> >>> --Eric >>> -- >>> The opinions expressed in this e-mail were randomly generated by >>> the computer and do not necessarily reflect the views of its owner. >>> --Management >>> --------------------------------------------------- >>> http://scratchcomputing.com >>> --------------------------------------------------- >>> _______________________________________________ >>> Kde-perl mailing list >>> Kde-perl@... >>> https://mail.kde.org/mailman/listinfo/kde-perl >>> >> _______________________________________________ >> Kde-perl mailing list >> Kde-perl@... >> https://mail.kde.org/mailman/listinfo/kde-perl >> > _______________________________________________ > Kde-perl mailing list > Kde-perl@... > https://mail.kde.org/mailman/listinfo/kde-perl > Kde-perl mailing list Kde-perl@... https://mail.kde.org/mailman/listinfo/kde-perl |
|
|
Re: Qt Compile Flags (Was: Compiling Without Installing)
by Chris Burel
::
Rate this Message:
> Right now the big push is
> fixing that nasty issue with the segfaults, so I'll fix my module, > finish compiling and hack on that. :-) What segfaults are you experiencing? _______________________________________________ Kde-perl mailing list Kde-perl@... https://mail.kde.org/mailman/listinfo/kde-perl |
|
|
Re: Qt Compile Flags (Was: Compiling Without Installing)
by Jonathan Yu
::
Rate this Message:
Well, it was the issue that was reported in code.google.org; that I
was initially brought into this project to get fixed, in the first place... On Wed, Jun 3, 2009 at 9:28 PM, Chris Burel <chrisburel@...> wrote: >> Right now the big push is >> fixing that nasty issue with the segfaults, so I'll fix my module, >> finish compiling and hack on that. :-) > > What segfaults are you experiencing? > _______________________________________________ > Kde-perl mailing list > Kde-perl@... > https://mail.kde.org/mailman/listinfo/kde-perl > Kde-perl mailing list Kde-perl@... https://mail.kde.org/mailman/listinfo/kde-perl |
|
|
Re: Qt Compile Flags (Was: Compiling Without Installing)
by Chris Burel
::
Rate this Message:
Was it this one?
http://code.google.com/p/perlqt4/issues/detail?id=3&can=1 That ended up being related to the perl compile options, related to how it handles allocating memory for environment variables. On Wed, Jun 3, 2009 at 6:31 PM, Jonathan Yu <jonathan.i.yu@...> wrote: > Well, it was the issue that was reported in code.google.org; that I > was initially brought into this project to get fixed, in the first > place... > > On Wed, Jun 3, 2009 at 9:28 PM, Chris Burel <chrisburel@...> wrote: >>> Right now the big push is >>> fixing that nasty issue with the segfaults, so I'll fix my module, >>> finish compiling and hack on that. :-) >> >> What segfaults are you experiencing? >> _______________________________________________ >> Kde-perl mailing list >> Kde-perl@... >> https://mail.kde.org/mailman/listinfo/kde-perl >> > _______________________________________________ > Kde-perl mailing list > Kde-perl@... > https://mail.kde.org/mailman/listinfo/kde-perl > Kde-perl mailing list Kde-perl@... https://mail.kde.org/mailman/listinfo/kde-perl |
|
|
Re: Qt Compile Flags (Was: Compiling Without Installing)
by Jonathan Yu
::
Rate this Message:
Impressive. Well, in that case, what is outstanding that you'd like me
to hack on? Is there a particular area you want me to focus on? On Wed, Jun 3, 2009 at 9:46 PM, Chris Burel <chrisburel@...> wrote: > Was it this one? > http://code.google.com/p/perlqt4/issues/detail?id=3&can=1 > > That ended up being related to the perl compile options, related to > how it handles allocating memory for environment variables. > > On Wed, Jun 3, 2009 at 6:31 PM, Jonathan Yu <jonathan.i.yu@...> wrote: >> Well, it was the issue that was reported in code.google.org; that I >> was initially brought into this project to get fixed, in the first >> place... >> >> On Wed, Jun 3, 2009 at 9:28 PM, Chris Burel <chrisburel@...> wrote: >>>> Right now the big push is >>>> fixing that nasty issue with the segfaults, so I'll fix my module, >>>> finish compiling and hack on that. :-) >>> >>> What segfaults are you experiencing? >>> _______________________________________________ >>> Kde-perl mailing list >>> Kde-perl@... >>> https://mail.kde.org/mailman/listinfo/kde-perl >>> >> _______________________________________________ >> Kde-perl mailing list >> Kde-perl@... >> https://mail.kde.org/mailman/listinfo/kde-perl >> > _______________________________________________ > Kde-perl mailing list > Kde-perl@... > https://mail.kde.org/mailman/listinfo/kde-perl > Kde-perl mailing list Kde-perl@... https://mail.kde.org/mailman/listinfo/kde-perl |
|
|
Re: Qt Compile Flags (Was: Compiling Without Installing)
by Jonathan Yu
::
Rate this Message:
Oh- Chris, we (ewilhelm and I) made a channel on irc.perl.org - #qt
If you can join, it's probably more useful for quick questions than the mailing list. Right now I'm getting an error building from source - see http://sial.org/pbot/37016 any ideas? On Wed, Jun 3, 2009 at 9:49 PM, Jonathan Yu <jonathan.i.yu@...> wrote: > Impressive. Well, in that case, what is outstanding that you'd like me > to hack on? Is there a particular area you want me to focus on? > > On Wed, Jun 3, 2009 at 9:46 PM, Chris Burel <chrisburel@...> wrote: >> Was it this one? >> http://code.google.com/p/perlqt4/issues/detail?id=3&can=1 >> >> That ended up being related to the perl compile options, related to >> how it handles allocating memory for environment variables. >> >> On Wed, Jun 3, 2009 at 6:31 PM, Jonathan Yu <jonathan.i.yu@...> wrote: >>> Well, it was the issue that was reported in code.google.org; that I >>> was initially brought into this project to get fixed, in the first >>> place... >>> >>> On Wed, Jun 3, 2009 at 9:28 PM, Chris Burel <chrisburel@...> wrote: >>>>> Right now the big push is >>>>> fixing that nasty issue with the segfaults, so I'll fix my module, >>>>> finish compiling and hack on that. :-) >>>> >>>> What segfaults are you experiencing? >>>> _______________________________________________ >>>> Kde-perl mailing list >>>> Kde-perl@... >>>> https://mail.kde.org/mailman/listinfo/kde-perl >>>> >>> _______________________________________________ >>> Kde-perl mailing list >>> Kde-perl@... >>> https://mail.kde.org/mailman/listinfo/kde-perl >>> >> _______________________________________________ >> Kde-perl mailing list >> Kde-perl@... >> https://mail.kde.org/mailman/listinfo/kde-perl >> > Kde-perl mailing list Kde-perl@... https://mail.kde.org/mailman/listinfo/kde-perl |
| Free embeddable forum powered by Nabble | Forum Help |
