-
-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Long output pauses in build #85
Comments
Hi Marius,
very good news! What about gmic_gimp plugin? At least the macports port gimp2 builds well and runs with gmic_gimp_qt!
Actually gmic is 2.0.1 and the build lasts quite long too. Interesting that the Port build needs nearly 400% CPU for building an my MacBook!
Karsten
… Am 24.06.2017 um 12:59 schrieb Marius Schamschula ***@***.***>:
Hi, I just took over as maintainer for gmic under MacPorts.
Although, the current version (2.2.1) builds cleanly on my local machine, I have run had two problems reported by other users:
Memory usage during parallel builds. I have disabled this, and heard back that the build now succeeds on machines with smaller amounts of RAM.
There are long pauses in output. So long (more than 20 minutes), that out build bots time out. See
https://trac.macports.org/ticket/54370 <https://trac.macports.org/ticket/54370>
Marius
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <#85>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABKUVz9h6xTpQu0QArp7dobjnG7kYMp9ks5sHOwMgaJpZM4OES1c>.
|
Yup. I mistyped (see edit of my original post). Since I updated the Portfile to prevent parallel builds, I haven't rebuilt gmic on my own machine. However, I've also heard my iMac rev up the fans during the last build. Given that machine has a i7 and lots of memory, it can only mean the CPU load was high. I haven't had time to test the Gimp plug-in. |
Even after increasing our timeout to 60 minutes, the problem still occurs. Why was this issue closed? |
Hmm, I'm a humble Mac user. Your log shows the usage of gmic 2.0.2. Actually the stable mac port version is gmic 2.8.3, which builds by installing. Maybe there is some change already?
The other side is, possibly you try to do the things bit too good! For the gmic app I wonder why you have gimp-2.0 in include and link pathes. Possibly showing your port file might be helpful .
… Am 05.02.2020 um 19:26 schrieb Ryan Schmidt ***@***.***>:
2. There are long pauses in output. So long (more than 20 minutes), that our build bots time out. See
https://trac.macports.org/ticket/54370 <https://trac.macports.org/ticket/54370>
Even after increasing our timeout to 60 minutes, the problem still occurs.
Why was this issue closed?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#85>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJJIVYITZHQJBIZRIBEDRLRBMAGRANCNFSM4DQRFVOA>.
|
The original bug report from several years ago was about 2.0.2. The problem remains with 2.8.3, per the log I've added to the original bug report.
You may view the Portfile at https://github.com/macports/macports-ports/blob/master/science/gmic/Portfile |
Hmm, my MacBook uses for building gmic gimp plugin about 15 min. The difference is -mmacosx-version-min=10.10 ! My build is only for min version 10.13. Perhaps version_min=10.12 could help? Not just well for users of older systems, still perhaps as a trial!
… Am 05.02.2020 um 20:11 schrieb Ryan Schmidt ***@***.***>:
Hmm, I'm a humble Mac user. Your log shows the usage of gmic 2.0.2. Actually the stable mac port version is gmic 2.8.3, which builds by installing. Maybe there is some change already?
The original bug report from several years ago was about 2.0.2. The problem remains with 2.8.3, per the log I've added to the original bug report.
The other side is, possibly you try to do the things bit too good! For the gmic app I wonder why you have gimp-2.0 in include and link pathes. Possibly showing your port file might be helpful .
You may view the Portfile at https://github.com/macports/macports-ports/blob/master/science/gmic/Portfile <https://github.com/macports/macports-ports/blob/master/science/gmic/Portfile>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#85>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJJIV6QOCP3Y2IT327YH33RBMFPBANCNFSM4DQRFVOA>.
|
The build log I linked to was from a machine running OS X 10.10. MacPorts usually specifies that the deployment target (the macosx-version-min, if you like) be the same as the OS version. We build for each OS version separately. I don't think the deployment target version should have any effect on this. It is probable that this build machine (which is a virtual machine) was slightly delayed by other busy virtual machines running on the same host. Nevertheless, a build process that allows an hour, 20 minutes, 5 minutes, or even 1 minute to elapse without printing some kind of status information to the console is broken as far as I'm concerned, and redesigning the gmic build system so that that no longer happens is what I would have expected to occur prior to this issue being closed. |
You might be right to expect some log messages. Still if the mac build system produces the unacceptable build times depending on OS version rspv. deployment target it might be difficult for the software designer without the appropriate system at hand. I think you should send this issue either to MacPorts or to apple.
… Am 05.02.2020 um 21:37 schrieb Ryan Schmidt ***@***.***>:
The build log I linked to was from a machine running OS X 10.10. MacPorts usually specifies that the deployment target (the macosx-version-min, if you like) be the same as the OS version. We build for each OS version separately. I don't think the deployment target version should have any effect on this. It is probable that this build machine (which is a virtual machine) was slightly delayed by other busy virtual machines running on the same host. Nevertheless, a build process that allows an hour, 20 minutes, 5 minutes, or even 1 minute to elapse without printing some kind of status information to the console is broken as far as I'm concerned, and redesigning the gmic build system so that that no longer happens is what I would have expected to occur prior to this issue being closed.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#85>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJJIV522M62TJMWXG2UB4DRBMPQVANCNFSM4DQRFVOA>.
|
There is no "mac build system". There is the gmic build system, being used on a Mac.
I have no reason to believe that that is the case. The gmic build system simply takes too long to build some things.
Apple has nothing to do with how long something takes to compile, neither does MacPorts. @Schamschula and I are MacPorts developers, reporting this defect in the gmic build system to the developers of gmic who are the only ones who can fix it. |
Ok, then use the appropriate list. gmic-community may not be appropriate, since I don't see any reaction from the developer. Use either the git message system of gmic, or https://discuss.pixls.us/c/software/gmic <https://discuss.pixls.us/c/software/gmic>!
Still the time differences are astounding with seemingly the exact same environment (macports updated and source same version)! Or do you have an idea why my little macbook needs 15min. and yours more than 60 ?
… Am 05.02.2020 um 21:54 schrieb Ryan Schmidt ***@***.***>:
if the mac build system
There is no "mac build system". There is the gmic build system, being used on a Mac.
produces the unacceptable build times depending on OS version rspv. deployment target
I have no reason to believe that that is the case. The gmic build system simply takes too long to build some things.
I think you should send this issue either to MacPorts or to apple.
Apple has nothing to do with how long something takes to compile, neither does MacPorts. @Schamschula <https://github.com/Schamschula> and I are MacPorts developers, reporting this defect in the gmic build system to the developers of gmic who are the only ones who can fix it.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#85>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJJIV5ZQDYJB5MIRTQNOFLRBMRQ7ANCNFSM4DQRFVOA>.
|
Ah. From the gmic web site, the Report Issue link goes to https://github.com/dtschump/gmic/issues. I guess this should have been reported there. No, I don't know why there is such a difference in time. Our servers are probably a bit slower than your MacBook, but I would not have expected such a large difference. But as I said the fact that it takes longer on our server than on your MacBook is not the problem; the fact that any individual step of the build takes more than, say, a minute is the problem. |
Hi, I just took over as maintainer for gmic under MacPorts.
Although, the current version (2.0.2) builds cleanly on my local machine, I have run had two problems reported by other users:
Memory usage during parallel builds. I have disabled this, and heard back that the build now succeeds on machines with smaller amounts of RAM.
There are long pauses in output. So long (more than 20 minutes), that our build bots time out. See
https://trac.macports.org/ticket/54370
Marius
The text was updated successfully, but these errors were encountered: