Re: Build issues

[Robert C. Helling]

Dirk,

> On 4. Jan 2020, at 20:07, Dirk Hohndel  wrote:
> 
> So for me this is an interesting dance. As long as I set the 
> QT_QPA_PLATFORM_PLUGIN_PATH to the right directory, I can usually get away 
> without running make install after every build - I only need it after the 
> first build. So in my case that's
> 
> QT_QPA_PLATFORM_PLUGIN_PATH=/Users/hohndel/Qt5.14.0/5.14.0/clang_64/plugins
> 
> Can you try if that works for you?
> 

that’s it! Indeed, this works for me as well.

Thanks a million
Robert


signature.asc
Description: Message signed with OpenPGP
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Build issues

[Thiago Macieira]

On Saturday, 4 January 2020 12:31:53 -03 Robert.Helling wrote:
> find Subsurface-mobile.app/ |grep dylib$|xargs -n1 otool -L
> 
> here: https://neu.atdotde.de/~robert/ot.out
> 
> Maybe you can spot something odd.

Ok, that will catch plugins (as they are .dylib), but not the libraries 
themselves. Those have a plain, undecorated name like "QtCore".

> + '[' '' = 1 ']'
> + (( i++  ))
> + (( i < 1  ))
> 
> [BTW: What is this?]

That's sh -x output, which is showing things after expansion.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel System Software Products



___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Build issues

[Dirk Hohndel]

> On Jan 4, 2020, at 11:00 AM, Robert Helling  wrote:
> 
> Subsurface-mobile 2.2.3 (4.9.3.693)  was from git log. The problem is, I 
> don’t know what I did that caused a write at all. I agree that this version 
> will contain the bug (if it wasn’t me doing something stupid), but I will 
> look into this to see if I can trigger it. I noticed this only as I looked 
> into the repository for something unrelated.

Thanks for clarifying that.

>> Then, ideally, revert that commit in a local copy of that cloud repo and 
>> start that same version of Subsurface locally and see if it does it again. 
>> And then all we need to do is bisect and figure out when this was introduced.
>> 
>> If you want me to do that I can. Please give me permission to access your 
>> cloud storage data.
> 
> Feel free to if you want to. I reset those commits and force pushed that so 
> it could well be that there is no trace of this. But I preserved it in a 
> branch named „neu“ which I pushed to the cloud.

Ok, I'll try to see if I can make sense of it.

> Regarding blowing away the build directory: I agree that this often helps, 
> unfortunately not in this case. I even tried to blow away the whole ./src and 
> start from scratch with a new clone but that reproduced the problem.
> 
> But as I said: Luckily, I can still get a working build, it’s just that every 
> compile cycle takes an additional minute that gets annoying when doing it 
> several times in a row.

So for me this is an interesting dance. As long as I set the 
QT_QPA_PLATFORM_PLUGIN_PATH to the right directory, I can usually get away 
without running make install after every build - I only need it after the first 
build. So in my case that's

QT_QPA_PLATFORM_PLUGIN_PATH=/Users/hohndel/Qt5.14.0/5.14.0/clang_64/plugins

Can you try if that works for you?

/D___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Build issues

[Robert Helling]

Dirk,

> On 4. Jan 2020, at 17:37, Dirk Hohndel  wrote:
> 
> That answer makes no sense, Robert.
> The version that messed up your data is the version that wrote the very 
> commit that removes the o2 value.
> So do a git log -p on your cloud repo and search for that specific change, 
> and then look which version of Subsurface wrote that commit - it's in the 
> commit message for that very reason.

Subsurface-mobile 2.2.3 (4.9.3.693)  was from git log. The problem is, I don’t 
know what I did that caused a write at all. I agree that this version will 
contain the bug (if it wasn’t me doing something stupid), but I will look into 
this to see if I can trigger it. I noticed this only as I looked into the 
repository for something unrelated.

> 
> Then, ideally, revert that commit in a local copy of that cloud repo and 
> start that same version of Subsurface locally and see if it does it again. 
> And then all we need to do is bisect and figure out when this was introduced.
> 
> If you want me to do that I can. Please give me permission to access your 
> cloud storage data.

Feel free to if you want to. I reset those commits and force pushed that so it 
could well be that there is no trace of this. But I preserved it in a branch 
named „neu“ which I pushed to the cloud.

Regarding blowing away the build directory: I agree that this often helps, 
unfortunately not in this case. I even tried to blow away the whole ./src and 
start from scratch with a new clone but that reproduced the problem.

But as I said: Luckily, I can still get a working build, it’s just that every 
compile cycle takes an additional minute that gets annoying when doing it 
several times in a row.

Best
Robert


signature.asc
Description: Message signed with OpenPGP
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Build issues

[Dirk Hohndel]

> On Jan 4, 2020, at 7:31 AM, Robert.Helling  wrote:
> 
> Thiago,
> 
> thanks for helping out.
> 
>> On 4. Jan 2020, at 15:14, Thiago Macieira > > wrote:
>> 
>> This looks like an incomplete deployment: some binary resources inside the 
>> bundle still point to the original files from the Qt SDK, not the bundled 
>> copy 
>> of the Qt frameworks. If you use otool -L on each of the binaries inside, 
>> can 
>> you find out which one still points to that "clang_64" build?
> 
> This does not seem to be the case. I put the output of 
> 
> find Subsurface-mobile.app/ |grep dylib$|xargs -n1 otool -L
> 
> here: https://neu.atdotde.de/~robert/ot.out 
> 
> 
> Maybe you can spot something odd.
> 
> I can also report that creating an empty directory, cloning a fresh copy of 
> Subsurface from GitHub and running subsurface/scripts/build.sh -mobile 
> produces exactly the same kind of problems (actually just this script 
> produces a disfucntional binary:
> 
> + '[' '' = 1 ']'
> + (( i++  ))
> + (( i < 1  ))
> 
> [BTW: What is this?]
> 
> thnbtmpmbp055:clean Helling$ cd subsurface/build-mobile/
> thnbtmpmbp055:build-mobile Helling$ Subsurface-mobile
> Subsurface-mobile.app/ Subsurface-mobile_autogen/
> thnbtmpmbp055:build-mobile Helling$ 
> Subsurface-mobile.app/Contents/MacOS/Subsurface-mobile 
> can't find Subsurface localization for locale "en-DE"
> QML import path 
> ("/Users/Helling/clean/subsurface/build-mobile/Subsurface-mobile.app/Contents/Frameworks",
>  
> "/Users/Helling/clean/subsurface/build-mobile/Subsurface-mobile.app/Contents/MacOS",
>  "qrc:/qt-project.org/imports ", 
> "/Users/Helling/clean/subsurface/build-mobile/Subsurface-mobile.app/Contents/Resources/qml")
> INFO: QQmlApplicationEngine failed to load component
> INFO: qrc:/qml/main.qml:868 Type Export unavailable
> qrc:/qml/Export.qml:15 Type FileDialog unavailable
> file:///Users/Helling/clean/subsurface/build-mobile/Subsurface-mobile.app/Contents/Resources/qml/QtQuick/Dialogs/DefaultFileDialog.qml:47
>  
> 
>  module "Qt.labs.folderlistmodel" is not installed
> file:///Users/Helling/clean/subsurface/build-mobile/Subsurface-mobile.app/Contents/Resources/qml/QtQuick/Dialogs/DefaultFileDialog.qml:48
>  
> 
>  module "Qt.labs.settings" is not installed
> file:///Users/Helling/clean/subsurface/build-mobile/Subsurface-mobile.app/Contents/Resources/qml/QtQuick/Dialogs/DefaultFileDialog.qml:47
>  
> 
>  module "Qt.labs.folderlistmodel" is not installed
> file:///Users/Helling/clean/subsurface/build-mobile/Subsurface-mobile.app/Contents/Resources/qml/QtQuick/Dialogs/DefaultFileDialog.qml:48
>  
> 
>  module "Qt.labs.settings" is not installed
> 
> INFO: loaded main.qml
> can't create window object
> 
> However, running make install in the build directory fixes this (modulo over 
> one minute of install_name_tool errors being displayed).
> 

Correct. I had this after a MacOS upgrade as well.
Blow away build directory.
run build.sh
then run make install again

after those three steps it reliably works for me

/D

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Build issues

[Dirk Hohndel]

> On Jan 4, 2020, at 1:50 AM, Robert Helling  wrote:
> 
> Tracking down the offending version that forgot the gas content: It was 
> Subsurface-mobile 2.2.3 (4.9.3.693) running on January 2nd. But I have not 
> been diving for several months and did not use the mobile version in a 
> similarly long time. So it could have been any version for a long time.

That answer makes no sense, Robert.
The version that messed up your data is the version that wrote the very commit 
that removes the o2 value.
So do a git log -p on your cloud repo and search for that specific change, and 
then look which version of Subsurface wrote that commit - it's in the commit 
message for that very reason.

Then, ideally, revert that commit in a local copy of that cloud repo and start 
that same version of Subsurface locally and see if it does it again. And then 
all we need to do is bisect and figure out when this was introduced.

If you want me to do that I can. Please give me permission to access your cloud 
storage data.

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Build issues

[Robert.Helling]

Thiago,

thanks for helping out.

> On 4. Jan 2020, at 15:14, Thiago Macieira  > wrote:
> 
> This looks like an incomplete deployment: some binary resources inside the 
> bundle still point to the original files from the Qt SDK, not the bundled 
> copy 
> of the Qt frameworks. If you use otool -L on each of the binaries inside, can 
> you find out which one still points to that "clang_64" build?

This does not seem to be the case. I put the output of 

find Subsurface-mobile.app/ |grep dylib$|xargs -n1 otool -L

here: https://neu.atdotde.de/~robert/ot.out 


Maybe you can spot something odd.

I can also report that creating an empty directory, cloning a fresh copy of 
Subsurface from GitHub and running subsurface/scripts/build.sh -mobile produces 
exactly the same kind of problems (actually just this script produces a 
disfucntional binary:

+ '[' '' = 1 ']'
+ (( i++  ))
+ (( i < 1  ))

[BTW: What is this?]

thnbtmpmbp055:clean Helling$ cd subsurface/build-mobile/
thnbtmpmbp055:build-mobile Helling$ Subsurface-mobile
Subsurface-mobile.app/ Subsurface-mobile_autogen/
thnbtmpmbp055:build-mobile Helling$ 
Subsurface-mobile.app/Contents/MacOS/Subsurface-mobile 
can't find Subsurface localization for locale "en-DE"
QML import path 
("/Users/Helling/clean/subsurface/build-mobile/Subsurface-mobile.app/Contents/Frameworks",
 
"/Users/Helling/clean/subsurface/build-mobile/Subsurface-mobile.app/Contents/MacOS",
 "qrc:/qt-project.org/imports ", 
"/Users/Helling/clean/subsurface/build-mobile/Subsurface-mobile.app/Contents/Resources/qml")
INFO: QQmlApplicationEngine failed to load component
INFO: qrc:/qml/main.qml:868 Type Export unavailable
qrc:/qml/Export.qml:15 Type FileDialog unavailable
file:///Users/Helling/clean/subsurface/build-mobile/Subsurface-mobile.app/Contents/Resources/qml/QtQuick/Dialogs/DefaultFileDialog.qml:47
 

 module "Qt.labs.folderlistmodel" is not installed
file:///Users/Helling/clean/subsurface/build-mobile/Subsurface-mobile.app/Contents/Resources/qml/QtQuick/Dialogs/DefaultFileDialog.qml:48
 

 module "Qt.labs.settings" is not installed
file:///Users/Helling/clean/subsurface/build-mobile/Subsurface-mobile.app/Contents/Resources/qml/QtQuick/Dialogs/DefaultFileDialog.qml:47
 

 module "Qt.labs.folderlistmodel" is not installed
file:///Users/Helling/clean/subsurface/build-mobile/Subsurface-mobile.app/Contents/Resources/qml/QtQuick/Dialogs/DefaultFileDialog.qml:48
 

 module "Qt.labs.settings" is not installed

INFO: loaded main.qml
can't create window object

However, running make install in the build directory fixes this (modulo over 
one minute of install_name_tool errors being displayed).

Best
Robert


___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Build issues

[Thiago Macieira]

On Friday, 3 January 2020 21:33:09 -03 Robert Helling wrote:
> > objc[85638]: Class
> > QT_ROOT_LEVEL_POOL__THESE_OBJECTS_WILL_BE_RELEASED_WHEN_QAPP_GOES_OUT_OF_
> > SCOPE is implemented in both
> > /Users/Helling/Qt/5.12.0/clang_64/lib/QtCore.framework/Versions/5/QtCore
> > (0x1025390e0) and
> > /Users/Helling/mobile/subsurface/build-mobile/Subsurface-mobile.app/Conte
> > nts/Frameworks/QtCore.framework/Versions/5/QtCore (0x1078750e0). One of
> > the two will be used. Which one is undefined.

This looks like an incomplete deployment: some binary resources inside the 
bundle still point to the original files from the Qt SDK, not the bundled copy 
of the Qt frameworks. If you use otool -L on each of the binaries inside, can 
you find out which one still points to that "clang_64" build?

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel System Software Products



___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Build issues

[Robert Helling]

Dirk,

> Am 04.01.2020 um 05:34 schrieb Dirk Hohndel :
> 
> Blow away your build directory and call build.sh from the directory above 
> Subsurface with the path set up correctly for your Qt version.
> That will fix all of the build time and run time issues

Unfortunately not. I have already done that a number of times.

I should also add that these issues are not new, they keep reoccurring. In 
particular, the errors of the install_name_tool have been around for a long 
time but now gotten so bad that the wait is really annoying.

Tracking down the offending version that forgot the gas content: It was 
Subsurface-mobile 2.2.3 (4.9.3.693) running on January 2nd. But I have not been 
diving for several months and did not use the mobile version in a similarly 
long time. So it could have been any version for a long time.

Best
Robert
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Build issues

[Dirk Hohndel]

Sorry, on my phone.
Blow away your build directory and call build.sh from the directory above 
Subsurface with the path set up correctly for your Qt version.
That will fix all of the build time and run time issues

The loss of gas info is very scary. If this is in git then you know which exact 
version wrote the bad data. Please let us know so we can track that down

/D

On January 3, 2020 4:33:09 PM PST, Robert Helling  wrote:
>Hi,
>
>after far too many weeks without any reasonable amount of time to worry
>about Subsurface, the new year has provided me with some hours of free
>time to catch up and hopefully come up to speed again. By now, I can
>build again both desktop as well as mobile-on-desktop (have not tried
>to build mobile but that used to work with the occasional code signing
>problem). But there are a few annoyances I have not been able to
>overcome. For all of them, I at least have work arounds but I would
>like to list them here as maybe anybody of you has any idea how to deal
>with them.
>
>Everything I do here is on MacOS Mojave. Hombrew should be up to date.
>
>To be able to build a working mobile on desktop, my Qt version was too
>old. I cannot recall which version I tried, besides some older ones, I
>had 5.10 and 5.12 installed, but now with 5.14 it works (™).
>
>I also had to update Qt Creator to make the debugger start. It actually
>shows source code and variables but breakpoints seem not to work (but I
>tried only briefly).
>
>When building from within Creator, the binary dies with
>
>> objc[85638]: Class QMacAutoReleasePoolTracker is implemented in both
>/Users/Helling/Qt/5.12.0/clang_64/lib/QtCore.framework/Versions/5/QtCore
>(0x102539068) and
>/Users/Helling/mobile/subsurface/build-mobile/Subsurface-mobile.app/Contents/Frameworks/QtCore.framework/Versions/5/QtCore
>(0x107875068). One of the two will be used. Which one is undefined.
>> objc[85638]: Class
>QT_ROOT_LEVEL_POOL__THESE_OBJECTS_WILL_BE_RELEASED_WHEN_QAPP_GOES_OUT_OF_SCOPE
>is implemented in both
>/Users/Helling/Qt/5.12.0/clang_64/lib/QtCore.framework/Versions/5/QtCore
>(0x1025390e0) and
>/Users/Helling/mobile/subsurface/build-mobile/Subsurface-mobile.app/Contents/Frameworks/QtCore.framework/Versions/5/QtCore
>(0x1078750e0). One of the two will be used. Which one is undefined.
>> objc[85638]: Class RunLoopModeTracker is implemented in both
>/Users/Helling/Qt/5.12.0/clang_64/lib/QtCore.framework/Versions/5/QtCore
>(0x102539108) and
>/Users/Helling/mobile/subsurface/build-mobile/Subsurface-mobile.app/Contents/Frameworks/QtCore.framework/Versions/5/QtCore
>(0x107875108). One of the two will be used. Which one is undefined.
>> 2020-01-04 01:21:43.358550+0100 Subsurface-mobile[85638:10548329]
>[qt.qpa.plugin] Could not load the Qt platform plugin "cocoa" in ""
>even though it was found.
>> 2020-01-04 01:21:43.358812+0100 Subsurface-mobile[85638:10548329]
>This application failed to start because no Qt platform plugin could be
>initialized. Reinstalling the application may fix this problem.
>> 
>> Available platform plugins are: cocoa.
>
>but running
>
>make -j2 install
>
>from the command line produces a working binary (which can also be run
>from within Creator)
>
>But this takes quite long (even with very little changed source code),
>as I get error messages like
>> 
>> ERROR: ""
>> ERROR:
>"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
>string table not at the end of the file (can't be processed) in file:
>Subsurface-mobile.app/Contents/Resources/qml/QtQuick/Extras/libqtquickextrasplugin.dylib.dSYM/Contents/Resources/DWARF/libqtquickextrasplugin.dylib\n"
>> ERROR: ""
>> ERROR:
>"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
>string table not at the end of the file (can't be processed) in file:
>Subsurface-mobile.app/Contents/Resources/qml/QtLocation/libdeclarative_location_debug.dylib.dSYM/Contents/Resources/DWARF/libdeclarative_location_debug.dylib\n"
>> ERROR: ""
>> ERROR:
>"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
>string table not at the end of the file (can't be processed) in file:
>Subsurface-mobile.app/Contents/Resources/qml/QtLocation/libdeclarative_location.dylib.dSYM/Contents/Resources/DWARF/libdeclarative_location.dylib\n"
>> ERROR: ""
>> ERROR:
>"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
>string table not at the end of the file (can't be processed) in file:
>Subsurface-mobile.app/Contents/Resources/qml/QtPositioning/libdeclarative_positioning.dylib.dSYM/Contents/Resources/DWARF/libdeclarative_positioning.dylib\n"
>> ERROR: ""
>> ERROR:
>"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
>string table not at the end of the file (can't be processed) in file:

Re: Build issues dive site management]

[Linus Torvalds]

On Sun, Feb 15, 2015 at 10:51 AM, Dirk Hohndel d...@hohndel.org wrote:

 Windows doesn't build right now since Linus used mkdir() - he had a
 comment there to that effect. Lubomir, can you help with a clean wrapper
 for that? Like a subsurface_mkdir()...?

Oh, I didn't think you were going to apply the last patch, so I didn't
worry too much about it.

You know what? Just remove the git-caches subdirectory entirely.
It's not needed, since the git caches will always do their own
(hashed) subdirectories anyway, and the biggest reason for it was that
originally I just used my home directory for the system directory,
and wanted to have a subdirectory rather than messing things up.

So I think the rigth thing to do is to just remove system_git_dir()
entirely, and replace its use with system_default_directory()
instead.

  Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Build issues dive site management]

[Lubomir I. Ivanov]

On 15 February 2015 at 21:24, Linus Torvalds
torva...@linux-foundation.org wrote:
 On Sun, Feb 15, 2015 at 11:16 AM, Lubomir I. Ivanov neolit...@gmail.com 
 wrote:

 seems like qmake generates a bogus rule for silent mode.

 No. It's simpler than that. Lookie here:

 Note the typo in subsurface-gen-version.pri:

   -silent: version_h.commands = @echo Checking $$VERSION_FILE 
 $$version_h.commads
   +silent: version_h.commands = @echo Checking $$VERSION_FILE 
 $$version_h.commands

 Heh.


oops, a copy / paste issue!
patch re-attached.

i blame Thiago :D,

On 12 February 2015 at 07:46, Thiago Macieira thi...@macieira.org wrote:
 silent: version_h.commands = @echo Checking $$VERSION_FILE 
 $$version_h.commads

lubomir
--


0006-PRI-fix-typo-in-the-version-generation-rule.patch
Description: Binary data
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Build issues

[Dirk Hohndel]

On Sun, Feb 15, 2015 at 08:55:07PM +0200, Lubomir I. Ivanov wrote:
 On 15 February 2015 at 20:51, Dirk Hohndel d...@hohndel.org wrote:
  On Sun, Feb 15, 2015 at 10:41:37AM -0800, Dirk Hohndel wrote:
 
  But I'll create a windows installer for you and put it somewhere. Give me
  a few minutes
 
  Heh. Easier said than done.
 
  Windows doesn't build right now since Linus used mkdir() - he had a
  comment there to that effect. Lubomir, can you help with a clean wrapper
  for that? Like a subsurface_mkdir()...?
 
 just sent a patch that fixes that (part of series of 5).

OK, I'll look into that series. Thanks.

  Also with the new write-version thingy... the first time I run make, I get
  something weird like sh: Syntax error, unexpected end of line in line:1
  Starting the make again works. Any idea what's up with that?
 
 can't seem to reproduce it...let me look into it again.
 Thiago said that it works for him (under Linux i assume).

I had this happen on Linux both native and cross building for Windows. But
only the first time I try it. Haven't done a clean checkout and tried
again.

I just ran into another problem. You removed a ton of stuff from
subsurface-install.pri that was used to set up the versions. You ignored
the fact that the variables used in that process are reused later in that
file both for Windows and Mac builds... So this all needs to be redesigned
in order to make sure that this data is now assembled at make time
(instead of at qmake time).

Right now this prevents me from doing my usual Windows and Mac builds :-(

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Build issues

[Lubomir I. Ivanov]

On 15 February 2015 at 21:01, Dirk Hohndel d...@hohndel.org wrote:
  Also with the new write-version thingy... the first time I run make, I get
  something weird like sh: Syntax error, unexpected end of line in line:1
  Starting the make again works. Any idea what's up with that?

 can't seem to reproduce it...let me look into it again.
 Thiago said that it works for him (under Linux i assume).

 I had this happen on Linux both native and cross building for Windows. But
 only the first time I try it. Haven't done a clean checkout and tried
 again.


that's odd.

 I just ran into another problem. You removed a ton of stuff from
 subsurface-install.pri that was used to set up the versions. You ignored
 the fact that the variables used in that process are reused later in that
 file both for Windows and Mac builds... So this all needs to be redesigned
 in order to make sure that this data is now assembled at make time
 (instead of at qmake time).

yakes, so variables from subsurface-gen-version.pri are used in
subsurface-install.pri.
FULL_VERSION, PRODVERSION_STRING to name a few.


 Right now this prevents me from doing my usual Windows and Mac builds :-(


sorry about that. this is way more entangled than i tough.
for now, i can just bring some of those variables as $system() calls
on qmake time?

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Build issues dive site management]

[Lubomir I. Ivanov]

On 15 February 2015 at 21:16, Lubomir I. Ivanov neolit...@gmail.com wrote:
 On 15 February 2015 at 21:10, Linus Torvalds
 torva...@linux-foundation.org wrote:
 On Sun, Feb 15, 2015 at 10:55 AM, Lubomir I. Ivanov neolit...@gmail.com 
 wrote:
 On 15 February 2015 at 20:51, Dirk Hohndel d...@hohndel.org wrote:

 Also with the new write-version thingy... the first time I run make, I get
 something weird like sh: Syntax error, unexpected end of line in line:1
 Starting the make again works. Any idea what's up with that?


 can't seem to reproduce it...let me look into it again.
 Thiago said that it works for him (under Linux i assume).

 It's broken for me too. The generated Makefile is broken, and looks like 
 this:

...
compiler_version_h_make_all: ssrf-version.h
compiler_version_h_clean:
   -$(DEL_FILE) ssrf-version.h
ssrf-version.h: . \
FORCE
@echo Checking /home/torvalds/src/subsurface/ssrf-version.h 

compiler_TSQM_make_all: translations/subsurface_source.qm
 translations/subsurface_bg_BG.qm translations/subsurface_cs.q$
...

 Note how it's just cut off after the @echo ...  line


 seems like qmake generates a bogus rule for silent mode.

 silent mode however is broken for me in general, so i need to find a
 solution how to test that.


this should be a quick fix (attached),
it was my original proposal, but later we added the silent: ... option.

CCing Thiago, if he has the time to help.

lubomir
--


0006-PRI-don-t-consider-silent-mode-for-the-version-gener.patch
Description: Binary data
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Build issues dive site management]

[Linus Torvalds]

On Sun, Feb 15, 2015 at 11:16 AM, Lubomir I. Ivanov neolit...@gmail.com wrote:

 seems like qmake generates a bogus rule for silent mode.

No. It's simpler than that. Lookie here:

Note the typo in subsurface-gen-version.pri:

  -silent: version_h.commands = @echo Checking $$VERSION_FILE 
$$version_h.commads
  +silent: version_h.commands = @echo Checking $$VERSION_FILE 
$$version_h.commands

Heh.

 Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Build issues

[Lubomir I. Ivanov]

On 15 February 2015 at 21:18, Dirk Hohndel d...@hohndel.org wrote:
 On Sun, Feb 15, 2015 at 09:12:18PM +0200, Lubomir I. Ivanov wrote:
 On 15 February 2015 at 21:01, Dirk Hohndel d...@hohndel.org wrote:
   Also with the new write-version thingy... the first time I run make, I 
   get
   something weird like sh: Syntax error, unexpected end of line in 
   line:1
   Starting the make again works. Any idea what's up with that?
 
  can't seem to reproduce it...let me look into it again.
  Thiago said that it works for him (under Linux i assume).
 
  I had this happen on Linux both native and cross building for Windows. But
  only the first time I try it. Haven't done a clean checkout and tried
  again.
 

 that's odd.

  I just ran into another problem. You removed a ton of stuff from
  subsurface-install.pri that was used to set up the versions. You ignored
  the fact that the variables used in that process are reused later in that
  file both for Windows and Mac builds... So this all needs to be redesigned
  in order to make sure that this data is now assembled at make time
  (instead of at qmake time).

 yakes, so variables from subsurface-gen-version.pri are used in
 subsurface-install.pri.
 FULL_VERSION, PRODVERSION_STRING to name a few.

 Yes, it's a mess. A complete idiot when it comes to qmake (i.e., me) has
 hacked this badly to make his setup work :-/

  Right now this prevents me from doing my usual Windows and Mac builds :-(

 sorry about that. this is way more entangled than i tough.
 for now, i can just bring some of those variables as $system() calls
 on qmake time?

 I gotta run and do family things for the next few hours. I'd love to see
 proposed patches that fix the mess :-)


FTM, this is what i can provide as a quick solution (attached).

it means that the -install.pri commands will be created on qmake-time,
which is still tolerable in a way.

one real problem is that i can't really work on the -install.pri
because i have no way to test it.
(e.g. no OSX and my DLL setup is completely different)

please, let me know if i missed a variable so that i can amend the patch!

ideally we should have external bourne scripts (like i did for
write-version), and minimize the code in -install.pri and Makefile*.
this will be easier to maintain since we all know how to write SH,
more or less.

lubomir
--


0007-PRI-include-some-variables-in-the-version-generation.patch
Description: Binary data
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Build issues dive site management]

[Davide DB]

don't worry I can wait when everything is stable.
 there are things more important

On Sun, Feb 15, 2015 at 7:51 PM, Dirk Hohndel d...@hohndel.org wrote:
 On Sun, Feb 15, 2015 at 10:41:37AM -0800, Dirk Hohndel wrote:

 But I'll create a windows installer for you and put it somewhere. Give me
 a few minutes

 Heh. Easier said than done.

 Windows doesn't build right now since Linus used mkdir() - he had a
 comment there to that effect. Lubomir, can you help with a clean wrapper
 for that? Like a subsurface_mkdir()...?

 Also with the new write-version thingy... the first time I run make, I get
 something weird like sh: Syntax error, unexpected end of line in line:1
 Starting the make again works. Any idea what's up with that?

 /D



-- 
Davide
https://vimeo.com/bocio/videos
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Build issues dive site management]

[Linus Torvalds]

On Sun, Feb 15, 2015 at 10:55 AM, Lubomir I. Ivanov neolit...@gmail.com wrote:
 On 15 February 2015 at 20:51, Dirk Hohndel d...@hohndel.org wrote:

 Also with the new write-version thingy... the first time I run make, I get
 something weird like sh: Syntax error, unexpected end of line in line:1
 Starting the make again works. Any idea what's up with that?


 can't seem to reproduce it...let me look into it again.
 Thiago said that it works for him (under Linux i assume).

It's broken for me too. The generated Makefile is broken, and looks like this:

   ...
   compiler_version_h_make_all: ssrf-version.h
   compiler_version_h_clean:
  -$(DEL_FILE) ssrf-version.h
   ssrf-version.h: . \
   FORCE
   @echo Checking /home/torvalds/src/subsurface/ssrf-version.h 

   compiler_TSQM_make_all: translations/subsurface_source.qm
translations/subsurface_bg_BG.qm translations/subsurface_cs.q$
   ...

Note how it's just cut off after the @echo ...  line

   Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Build issues dive site management]

[Lubomir I. Ivanov]

On 15 February 2015 at 21:10, Linus Torvalds
torva...@linux-foundation.org wrote:
 On Sun, Feb 15, 2015 at 10:55 AM, Lubomir I. Ivanov neolit...@gmail.com 
 wrote:
 On 15 February 2015 at 20:51, Dirk Hohndel d...@hohndel.org wrote:

 Also with the new write-version thingy... the first time I run make, I get
 something weird like sh: Syntax error, unexpected end of line in line:1
 Starting the make again works. Any idea what's up with that?


 can't seem to reproduce it...let me look into it again.
 Thiago said that it works for him (under Linux i assume).

 It's broken for me too. The generated Makefile is broken, and looks like this:

...
compiler_version_h_make_all: ssrf-version.h
compiler_version_h_clean:
   -$(DEL_FILE) ssrf-version.h
ssrf-version.h: . \
FORCE
@echo Checking /home/torvalds/src/subsurface/ssrf-version.h 

compiler_TSQM_make_all: translations/subsurface_source.qm
 translations/subsurface_bg_BG.qm translations/subsurface_cs.q$
...

 Note how it's just cut off after the @echo ...  line


seems like qmake generates a bogus rule for silent mode.

silent mode however is broken for me in general, so i need to find a
solution how to test that.

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Build issues

[Dirk Hohndel]

On Sun, Feb 15, 2015 at 09:12:18PM +0200, Lubomir I. Ivanov wrote:
 On 15 February 2015 at 21:01, Dirk Hohndel d...@hohndel.org wrote:
   Also with the new write-version thingy... the first time I run make, I 
   get
   something weird like sh: Syntax error, unexpected end of line in line:1
   Starting the make again works. Any idea what's up with that?
 
  can't seem to reproduce it...let me look into it again.
  Thiago said that it works for him (under Linux i assume).
 
  I had this happen on Linux both native and cross building for Windows. But
  only the first time I try it. Haven't done a clean checkout and tried
  again.
 
 
 that's odd.
 
  I just ran into another problem. You removed a ton of stuff from
  subsurface-install.pri that was used to set up the versions. You ignored
  the fact that the variables used in that process are reused later in that
  file both for Windows and Mac builds... So this all needs to be redesigned
  in order to make sure that this data is now assembled at make time
  (instead of at qmake time).
 
 yakes, so variables from subsurface-gen-version.pri are used in
 subsurface-install.pri.
 FULL_VERSION, PRODVERSION_STRING to name a few.

Yes, it's a mess. A complete idiot when it comes to qmake (i.e., me) has
hacked this badly to make his setup work :-/

  Right now this prevents me from doing my usual Windows and Mac builds :-(
 
 sorry about that. this is way more entangled than i tough.
 for now, i can just bring some of those variables as $system() calls
 on qmake time?

I gotta run and do family things for the next few hours. I'd love to see
proposed patches that fix the mess :-)

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface