ana(conda) windows packaging
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: ana(conda) windows packaging
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.
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.
Re: ana(conda) windows packaging
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.
Re: ana(conda) windows packaging
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.
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.
Re: ana(conda) windows packaging
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
Code: Select all
conda create -p $TRAVIS_BUILD_DIR/conda/AppDir/usr freecad
Re: ana(conda) windows packaging
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.
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 wrote: ↑Tue Sep 18, 2018 1:39 pm 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:
Re: ana(conda) windows packaging
I did some tests and using the approach:
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:
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?
Code: Select all
conda create -p $TRAVIS_BUILD_DIR/conda/AppDir/usr freecad
Code: Select all
conda remove mkl --force
Automatically or done manually?
Re: ana(conda) windows packaging
It's done manually by increasing the build-number.
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...
Re: ana(conda) windows packaging
Hi @looo
I likely won't have any time to look into this in the next 2 to 3 days. As for:
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.
I likely won't have any time to look into this in the next 2 to 3 days. As for:
I see (looo-ci is still needed).
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.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...
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.I also found another weak point of appimages: pip-packages installed as editable (development) are not recognized...
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.
Re: ana(conda) windows packaging
Yes if you add the channel freecad/label/dev the latest build should be used where the version info works.
Re: ana(conda) windows packaging
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
https://github.com/looooo/freecad_conda ... age.sh#L14