ana(conda) windows packaging

[7ofNine]

Yes it should, and I am talking only about the third party libraries not FreeCAD itself. If anybody wants to build FreeCAD with debug info that is up to the them. I do it. The problem one encounters in plain debug mode is that the setup is in such a way that all kinds of libraries are slightly renamed or even in some cases interfaces can be slightly changed which generates link errors. Theoretically one could do a FreeCAD debug build and leave all the libraries in release, but that is not how the whole system is setup and I have no intention to suggest to change that, but it is possible and some projects I have seen do this. It requires some care with naming and settings of pre-processor directives in imported *.h files.
In a "release with debug info" everything gets compiled and linked like release but some *.pdb files are generated in addition that give you the possibility to run the whole build in debug and set breakpoints etc. The disadvantage is that some of the optimizations lead to variables etc. that can not be read or sometimes funny looking jumps in the source (if one steps along) because the optimization did some changes that are not reflected in the debug data. But one can debug and go along with it. In any case better than what is currently available. And the best thing is that one can run it in release and has no speed penalty, all optimizations are turned on. Somebody who has no interest in debug can run it and doesn't get penalized. You should try it in some simple areas just to see how it works.

[7ofNine]

I just tried to verify my statements and they have to be corrected slightly. I see some size differences between plain release and release with debug for the *.exe and *.dll files. I always had the opinion(!) that there is no difference to the release build. I have to find out now what the differences are. Optimizations are still turned on and one can see the red flags that variables have been optimized away etc. I'll try to find out what is happening in some more detail.

[7ofNine]

I had to look into the executables to get some real info. There are mainly some data structures and names added as well as some debug hooks. The hooks are only executed when the debugger gets attached and are performance irrelevant. The optimizations of the code are the same as in the release case with a small exception for C++ exceptions and inline functions. For inline functions only explicitly declared ones are made inline (not "any feasible") and for C++ exceptions, which are hopefully not normal anyways, "exceptions with SEH" is changed to "exceptions" which is even according to MS typically the better idea anyways because of better compatibility.
One can still keep it separate from a plain release build, some folder name juggling might be needed, but one avoids all the problems that pop up for plain debug builds. It would be a release build with some features added. Just an idea to think about. It wouldn't be a complete debug build of the libraries but would ease the pain not to have the ability to debug at all.

[triplus]

Ok I somehow managed to upload packages from circle-ci to the freecad-channel (osx and linux) for now. This means that I am able to use git directly and the version.h should be correctly setup (hopefully).

Great. Therefore an automatic build each day should be possible now? Now when the version information got sorted out i investigated further and currently we do it like this on Travis and as seen in your example:

Code: Select all

conda create -p $TRAVIS_BUILD_DIR/conda/AppDir/usr --file freecad-spec-file.txt --copy

But as freecad-spec-file.txt doesn't get updated automatically the version of FreeCAD in the AppImage won't get updated. Some specific version of package(s) from freecad-spec-file.txt will i guess get used. Therefore is it possible to just do something like this instead:

Code: Select all

conda create -p $TRAVIS_BUILD_DIR/conda/AppDir/usr freecad

And for the (latest) FreeCAD and dependencies to get pulled in? Didn't test it yet as i figured it's worth to ask this question anyway.

[looo]

Great. Therefore an automatic build each day should be possible now?

I am not the biggest fan of every day builds. I think that is too much. I will do new builds once a week on sundays.

But as freecad-spec-file.txt doesn't get updated automatically the version of FreeCAD in the AppImage won't get updated. Some specific version of package(s) from freecad-spec-file.txt will i guess get used. Therefore is it possible to just do something like this instead:

Should be possible, but the version file excluded some deps that are not necessary. Maybe it's possible to lower the pinning restriction of some packages by removing the version or replacing it with a "*". But I didn't try this yet.

[triplus]

I did some tests and using the approach:

Code: Select all

conda create -p $TRAVIS_BUILD_DIR/conda/AppDir/usr freecad

It works as things like latest OCCT gets pulled in automatically. As for the size. I noticed some strange dependencies get pulled in like Intel MKL. This dependency alone weights around 200MB. Likely it is related to TBB but AFAIK it's redundant from FreeCAD perspective. If you can't remove it i can workaround that by using something like:

Code: Select all

conda remove mkl --force

That reduced the size of the AppImage by almost half. I noticed a few others dependencies like PyQt, Theora ... The same can likely be done there too. But there still is one issue. I tested all the things i could think of. Channels conda-forge and freecad added. Is freecad channel needed for creating AppImage purposes? And there still was no version information available in FreeCAD. I tried to update the freecad package with the --no-pin option. Just in case if by default i would be getting an older FreeCAD build. It doesn't look like version information is yet available?

I am not the biggest fan of every day builds. I think that is too much. I will do new builds once a week on sundays.

Automatically or done manually?

[looo]

Automatically or done manually?

It's done manually by increasing the build-number.

I did some tests and using the approach:

Please have a look at https://github.com/looooo/freecad_conda ... ppimage.sh . I modified the script a bit. To avoid mkl use the blas=*=openblas specification. The size is still a bit more than the previous appimage...

I also found another weak point of appimages: pip-packages installed as editable (development) are not recognized...

[triplus]

Hi @looo

I likely won't have any time to look into this in the next 2 to 3 days. As for:

It's done manually by increasing the build-number.

I see (looo-ci is still needed).

Please have a look at https://github.com/looooo/freecad_conda ... ppimage.sh . I modified the script a bit. To avoid mkl use the blas=*=openblas specification. The size is still a bit more than the previous appimage...

To be honest i likely won't look into this too much in-depth. Therefore if mkl will get pulled in i will just remove it and that is that. Thanks for listing out other dependencies for removal. Saves me some time when i will get back to it.

I also found another weak point of appimages: pip-packages installed as editable (development) are not recognized...

Likely some solution could be found. First i guess FreeCAD end users should start using pip packages. And if i understand you correctly for regular end users pip install without the -e option should still work just fine? Therefore i don't really see a problem here for now.

P.S. The main question (from yesterday) remains. Should the FreeCAD package from Conda now have correct version information included? I was under the impression it should have it now? But i don't see it in my tests.

[looo]

P.S. The main question (from yesterday) remains. Should the FreeCAD package from Conda now have correct version information included? I was under the impression it should have it now? But i don't see it in my tests.

Yes if you add the channel freecad/label/dev the latest build should be used where the version info works.

[looo]

After some further testing it seems pip is fully working with the appimage. But subprocess commands are a bit more difficult to handle... Maybe you can add my pip module to the appimage to get it tested a bit more:
https://github.com/looooo/freecad_conda ... age.sh#L14