Freecad 0.16 source.tar.gz out of date?

[fafc]

Hey,
regarding my other topic, the packager wanted to build 0.16 anew, however CMakelists.txt implies just patch number 4665 instead of 6700.

From https://github.com/FreeCAD/FreeCAD/archive/0.16.tar.gz, CMakelists.txt:

Code: Select all

project(FreeCAD_trunk)
set(FREECAD_VERSION "0.16")

set(PACKAGE_NAME "FreeCAD")
set(PACKAGE_VERSION_MAJOR "0")
set(PACKAGE_VERSION_MINOR "16")
set(PACKAGE_VERSION_PATCH "4665")
...

So could it be that the src tar is out of date or how is one supposed to compile the 0.16-6700 version?

[NormandC]

The packager needs to git clone the releases/FreeCAD-0-16 branch.
https://github.com/FreeCAD/FreeCAD/tree ... eeCAD-0-16

Or on the link above, click on the "Click or download" button. IIRC In either case he needs to run cake to generate the Version.h file.

[fafc]

Hmm, ok but thats kind of bad - because it is unexpected.

Our (from Chakra), but also the build script from Arch linux (link) point to the tar.gz - possible also these from other distros.

Which means there might be a couple of users out there who do not have the latest 0.16 release (but think so).


Any chance of updating the 0.16.tar.gz, since it is released now?

[sgrogan]

Any chance of updating the 0.16.tar.gz, since it is released now?

Done https://github.com/FreeCAD/FreeCAD/releases
Direct link https://github.com/FreeCAD/FreeCAD/rele ... 706.tar.gz

regarding my other topic, the packager wanted to build 0.16 anew, however CMakelists.txt implies just patch number 4665 instead of 6700.

The version in cmake is not the version of the source, it is the version at a known commit and at build time cmake runs a macro that counts commits from there to determine the version. I don't know if this works when building with the .tar.gz. You may need to manually edit the version.h file after running cmake. For reference the Source code .tar.gz is version 0.16.6700. My Direct link points to 0.16.6706 that contains the back ported bug fixes since the original 0.16.6700 release.

[fafc]

Hey srogan,
thanks a lot for your quick help!

... However as I wrote earlier the packages are build using a script with

Code: Select all

source=("$pkgname-$pkgver.tar.gz::https://github.com/FreeCAD/FreeCAD/archive/$pkgver.tar.gz"

(whereas pkgver = 0.16)

And with your new URL that doesn't fit... so "my" packager will not be so happy about it and furthermore it will also not affect the other distros out there who have also used (and still use) the https://github.com/FreeCAD/FreeCAD/archive/0.16.tar.gz link...

So I was wondering if you can either replace/update the above mentioned '0.16.tar.gz' ...

or if you say that this will be from now on the new scheme, ie:

Code: Select all

https://github.com/FreeCAD/FreeCAD/releases/download/$version/FreeCAD-$version.$commitcount.tar.gz 

then I'm also fine with it.

Thanks again.

[sgrogan]

And with your new URL that doesn't fit... so "my" packager will not be so happy about it and furthermore it will also not affect the other distros out there who have also used (and still use) the https://github.com/FreeCAD/FreeCAD/archive/0.16.tar.gz link...

The only way to fix this would be to delete the existing release and create a new one every time there is a backport and this would interfere with the OSX (and soon Windows) auto deployment
Could you see if this would work?

Code: Select all

https://github.com/FreeCAD/FreeCAD/archive/releases/FreeCAD-0-16.tar.gz

This should point to the HEAD of the release branch and not the releases page and should always be the latest. I can't test now, but I know it works with a .zip extension.

[fafc]

Ok, yes it works, but why 0-16 instead of 0.16 in the URL???

[sgrogan]

Ok, yes it works, but why 0-16 instead of 0.16 in the URL???

Some progress that's good! 0-16 is dictated by the naming of the branch when created.
@Yorik, if you see this any comments? I personally avoid special characters and spaces in file paths, always dash or underscore to avoid potential problems whether it's supposed to work or not.

[NormandC]

The version in cmake is not the version of the source, it is the version at a known commit and at build time cmake runs a macro that counts commits from there to determine the version. I don't know if this works when building with the .tar.gz.

How did you build it? If you used the method implemented by wmayer that I described here, then the Version.h file should have been generated with the proper info.

Edit: after waiting 10 minutes for the download to complete (boy is Github slow), I could get a look inside the tarball. There is no Version.h file in /src/Build.

You may need to manually edit the version.h file after running cmake.

The first law of a packager is: never modify the source. Patch it alright, but leave the source itself untouched.

[sgrogan]

The first law of a packager is: never modify the source. Patch it alright, but leave the source itself untouched.

Correct! Everything is autogenerated by github. I created a new release on github, tagged at the HEAD of the 0-16 release branch. I copied the aurogenerated .zip and .tar.bz files to the existing release and deleted the new release.
The problem with creating a new release for every backport is that it will break the totally automated OSX builds. On OSX every pull request is built and tested. Every push to master (release or dev) is built tested and deployed. @bblacey set this up for OSX with Travis-CI and @saso has us 90% here for Win$. OSX uses the https://github.com/FreeCAD/FreeCAD-ports-cache on Win we have the libpack, Win is far less transparent. There is no Win package manager so every dependency of every dependency must be either locally compiled or suitable pre-compiled binary must be found and integrated into the libpack.
This is where Linux package management has a huge advantage. On Win an equivalent would require a PPA equivalent to every dependency of FreeCAD, or at least a "stable" link to a pre-compiled version built with a compatible compiler.