Compiling on Mac fails

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Post Reply
nyholku
Posts: 149
Joined: Wed Dec 28, 2016 4:18 pm

Compiling on Mac fails

Post by nyholku »

Hi I'm trying and seeing if I can get back into the saddle and contribute something, perhaps improve my NaviCube but as always bit rot has set in in my absence and the toolchain is broken.

I posted about this here:

https://forum.freecadweb.org/viewtopic.php?f=4&t=35259

but maybe this is a better place.

To me it looks like this is Python3 related issue.

Obviously CMake detects std Mac Python i.e. 2.7 but the the three argument version of PyString_AsStringAndSize is a Python3 thing right?

So I tried to specify PYTHON_EXECUTABLE on the CMake command line but the code to detect the python headers in the CMakeLists.txt is not python3 compliant so that did not work.

So I specified PYTHON_INCLUDE_DIR manually too, but this just lead to PYTHON_LIBRARY not defined error.

At this point I thought I'd ask here as surely someone has stumbled upon this before and/or I'm following the wrong instructions here because I don't see how the PYTHON_INCLUDE_DIR could be detected with the

Code: Select all

 execute_process(COMMAND ${PYTHON_EXECUTABLE} -c  "from distutils.sysconfig import get_python_inc;print get_python_inc()"
as the print statement is not compatible with Python3

I am missing something, but what?

wbr Kusti
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Compiling on Mac fails

Post by wmayer »

Obviously CMake detects std Mac Python i.e. 2.7 but the the three argument version of PyString_AsStringAndSize is a Python3 thing right?
In Python2 there were two string-related classes: unicode and str and in Python3 there are str (which was unicode in Python2) and bytes. In the C API of Python all functions starting with "PyString_" have been removed so this means that PyString_AsStringAndSize is a Python2-only function that doesn't exist in Python3 any more.

In the other post I wrote that the build failure is caused by git commit 3ad9ee6f because there was an API change between 3.6 and 3.7 where the function PyUnicode_AsUTF8AndSize now returns a const char* while before it was a char*. See also https://docs.python.org/3/c-api/unicode.html

So, the correction for Python3.7 by accident broke the build for Python2.7. To continue for now just remove the const keyword. I will prepare a proper fix for this soon.
nyholku
Posts: 149
Joined: Wed Dec 28, 2016 4:18 pm

Re: Compiling on Mac fails

Post by nyholku »

So I was on the wrong track. Ok.

After the removing the 'conts' as you suggested the code compile completed last night and runs(at least starts) without problems.

Many thanks!



wbr Kusti

PS Incidents like this make me think that adding 'const' to the C++ language was of a dubious advantage at best.
ezzieyguywuf
Posts: 656
Joined: Tue May 19, 2015 1:11 am

Re: Compiling on Mac fails

Post by ezzieyguywuf »

nyholku wrote: Thu Mar 28, 2019 10:08 am PS Incidents like this make me think that adding 'const' to the C++ language was of a dubious advantage at best.
Not to get too "political" here, but the 'const' feature in C++ is a good feature when used correctly, and helps to ensure clarity in code as well as non-ambiguous interface definitions.

This SO article talks about why 'const' is a good thing, and it links this FAQ from isocpp.org

While I agree that `const` can be a bit cumbersome when you start to use it, in the long run it can prevent many weird bugs and unexpected behaviour.
nyholku
Posts: 149
Joined: Wed Dec 28, 2016 4:18 pm

Re: Compiling on Mac fails

Post by nyholku »

I was half joking and jesting re const ... but

you and many others have said in the 'long run' it will make things better ... well it has been long enough in my life (I ditched C++ from daily life some 15 years ago) and whenever circumstance forces me back still const seems to create more trouble than it is worth.

Const correctness has the same odor as language features that prevent NPE.

But that is just my personal opinion and I can live with it [const].

cheers Kusti
ezzieyguywuf
Posts: 656
Joined: Tue May 19, 2015 1:11 am

Re: Compiling on Mac fails

Post by ezzieyguywuf »

What I mean by "in the long run" is "as the code base grows and ages".

There are many times where you know exactly what you mean when you originally write a function, but months/years later, when you're not thinking about it, you end up mis-using it. This can be avoided by being more explicit in your code.

Here is an example, which while derived, does reflect a situation that I've seen in the past:

Code: Select all

class MyClass{
    public:
        std::string showData(){return myData;}
    
    private:
        std::string myData;
};
I can happily use "MyClass:showData" any time I want to see what data "MyClass" is storing. But what if later, someone decides to rewrite the "showData" method?

Code: Select all

std::string MyClass::showData()
{
    myData = myData.append("_");
    return myData;
}
This is obviously a poor coding practice, but there is nothing in the class definition that prevents this. If instead, MyClass had been defined as:

Code: Select all

class MyClass{
    public:
        std::string showData() const;
    
    private:
        std::string myData;
};
Then you are being very explicit to the user that this method does not modify MyClass at all.

"const" becomes even more useful when you begin passing values around by reference. Consider the following:

Code: Select all

class MyClass{
    public:
        void doSomething1(LargeClass data);
        void doSomething2(LargeClass& data);
        void doSomething3(const LargeClass& data) const;
};
The "doSomething1" version is undesirable, since every time it is called a copy of "LargeClass" is made, which will probably be an "expensive" function.

"doSomething2" is better, in that it does not make a copy of "LargeClass". Rather, it uses whatever instance the caller has on hand. However, this version is dangerous in that it could mutate "LargeClass", and the caller may not be expecting it. If instead the function were named, say, "modifyLargeClass", this would be less of a concern.

Finally, "doSomething3" would be the preferred way to define this method. As you can see, it makes it explicit that:
  1. I require a "LargeClass" in order to do my business
  2. I do not need to modify the "LargeClass" in order to do my business. Thus, I will accept a reference in order to save memory
  3. I do not need to modify myself to do my business
If "const correctness" is used reliably throughout the code base, then using "doSomething2" is no longer scary. This is because the user explicitly knows:

  1. I require a reference to an existing "LargeClass" in order to do my business
  2. I may modify the reference to "LargeClass" that you give me
  3. I may modify myself while I am doing my business
I could go on, but I do not wish to belabor the point. Besides, it seems that it is mostly a personal preference of yours to stay away from c++/const altogether, and really, what can I say about that but cheers! :lol:
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Compiling on Mac fails

Post by wmayer »

PS Incidents like this make me think that adding 'const' to the C++ language was of a dubious advantage at best.
The const keyword is a great feature, especially for C++ classes. Unfortunately, many developers don't use it only because of laziness and thus they don't benefit from its advantage. The point is when using it properly then it reduces a lot of possible side-effects which in many cases the compiler already tells you.

EDIT:
Another advantage is that it can improve performance:
https://stackoverflow.com/questions/343 ... erformance
https://herbsutter.com/2008/01/01/gotw- ... ant-const/
ezzieyguywuf
Posts: 656
Joined: Tue May 19, 2015 1:11 am

Re: Compiling on Mac fails

Post by ezzieyguywuf »

wmayer wrote: Thu Mar 28, 2019 5:25 pm The const keyword is a great feature, especially for C++ classes. Unfortunately, many developers don't use it only because of laziness and thus they don't benefit from its advantage. The point is when using it properly then it reduces a lot of possible side-effects which in many cases the compiler already tells you.
+1
nyholku
Posts: 149
Joined: Wed Dec 28, 2016 4:18 pm

Re: Compiling on Mac fails

Post by nyholku »

In theory yes, in practice not so sure.

If we take (if we could) the global sum of extra work and grief created by the pursuit of const correctness and compare it to the alleged reduction of bugs and savings in maintenance and debugging I think we are still in the red.

In summary, I'm ok if a project wants to pursue it, I'm ready to follow the style of any project I work in/with, but I'm not convinced.


cheers Kusti
Post Reply