HOWTO: Compiling LibreCAD with Visual Studio 2003 (and Qt 4.3.1 ...)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

HOWTO: Compiling LibreCAD with Visual Studio 2003 (and Qt 4.3.1 ...)

tin-pot
I have built the current LibreCAD source tree with VS .NET 2003, using Qt 4.3.1 (the Qt version is more by accident and stubbornness ...), this made some source changes necessary. The modified sources are in my own GitHub clone of LibreCAD.

In the hope that someone else might find this useful, I have added a description to the "Compile HOWTO" page in the GibHub wiki:

https://github.com/LibreCAD/LibreCAD/wiki/Compile-HOWTO


In the course of this, some questions arised (I'm new to Git - please bear with me!):

-  I have cloned the LibreCAD/LibreCAD Git, made a local working copy at home and comitted changes back to my clode Git - so far this seems all right.

- As I understand, I can issue a "push request", so that the powers that be can incorporate my changes to the "master" repository - is this right?

- How can I update changes that occur in LibreCAD/LibreCAD into my repository tin-pot/LibreCAD? Do I initiate this explicitly ("pull")? How are changes merged? How are conflicts going to be resolved (in SVN parlance)?


On another topic, I stumbled across the usage of isnormal() in rs_arc.cpp, rs_ellipse.cpp, rs_modification.cpp: is the intent really to exclude denormals (and of course zero, INFs and NANs) or is it meant to check if a value is finite and nonzero, maybe with a lower bound on magnitude? And if so, are infinities purposefully used in LibreCAD?
Reply | Threaded
Open this post in threaded view
|

Re: HOWTO: Compiling LibreCAD with Visual Studio 2003 (and Qt 4.3.1 ...)

dxli

-  I have cloned the LibreCAD/LibreCAD Git, made a local working copy at home and comitted changes back to my clode Git - so far this seems all right.

- As I understand, I can issue a "push request", so that the powers that be can incorporate my changes to the "master" repository - is this right?
 
for help on pull request at github,

http://help.github.com/send-pull-requests/

by clicking on "You are asking blahblah to pull # commits into blahblah from blahblah", you can also send pull request to my repository: https://github.com/dxli/LibreCAD


- How can I update changes that occur in LibreCAD/LibreCAD into my repository tin-pot/LibreCAD? Do I initiate this explicitly ("pull")? How are changes merged? How are conflicts going to be resolved (in SVN parlance)?
I found it's easier for me to keep another remote:

Let's say I have my local repository /home/dli/github/LibreCAD cloned from my repository: https://github.com/dxli/LibreCAD

$ cd /home/dli/github
$ git clone [hidden email]:dxli/LibreCAD.git
$ cd /home/dli/github/LibreCAD

Now add a remote "upstream" to it

$ git remote add upstream [hidden email]:LibreCAD/LibreCAD.git
( the LibreCAD/LibreCAD is added as remote named "upstream" )
$ git fetch --all
( the fetches remote refs to local, you only need to run it once here, most likely)
$ git checkout -f -b LC upstream/master
( this checks out the master branch of upstream to a local branch named LC )
$ git checkout master
$ git merge LC

Later on, you simply run the following to merge upstream changes,

$ git checkout LC
$ git pull
$ git checkout master
$ git merge LC


On another topic, I stumbled across the usage of isnormal() in rs_arc.cpp, rs_ellipse.cpp, rs_modification.cpp: is the intent really to exclude denormals (and of course zero, INFs and NANs) or is it meant to check if a value is finite and nonzero, maybe with a lower bound on magnitude? And if so, are infinities purposefully used in LibreCAD?

std::isnormal() is used to verify the number is not zero (of cause, not NAN/INF). We use it to tell the difference between ellipse arc and whole ellipses. For example, an ellipse arc has start/end angles, if both are set to be exactly zero ( isnormal() = false), we treat the ellipse arc as an whole ellipse. This is different from an whole range arc, because an arc from 0 to 2 Pi will still have a start/end point, while a whole ellipse has no start/end point.

I suppose std::isnormal() is C++ standard, we just have to figure out how to use it in windows.

Thanks and happy holidays!

--
Dongxu Li, Ph.D.
Reply | Threaded
Open this post in threaded view
|

Re: HOWTO: Compiling LibreCAD with Visual Studio 2003 (and Qt 4.3.1 ...)

tin-pot
Hi Dongxu,

thank you for the help on Git! I'll try it out soon.

dxli wrote
std::isnormal() is used to verify the number is not zero (of cause, not
NAN/INF). We use it to tell the difference between ellipse arc and whole
ellipses. For example, an ellipse arc has start/end angles, if both are set
to be exactly zero ( isnormal() = false), we treat the ellipse arc as an
whole ellipse. This is different from an whole range arc, because an arc
from 0 to 2 Pi will still have a start/end point, while a whole ellipse has
no start/end point.
I see. I just wondered if a simple comparison to zero wouldn't do the
job easier. Or, even easier - and safer - have a three-valued orientation
flag (CW arc, CCW arc, full turn); this would mirror the situation with
circular arcs/circles.

dxli wrote
I suppose std::isnormal() is C++ standard, we just have to figure out how
to use it in windows.
Well, kind of: AFAIK it was first specified in C99 (ISO 9899:1999) and then
adopted in <cmath> of C++11 (ISO 14882:2011). I don't know how
common C++11 is supported today - current MSVC versions up to 2010
obviously don't care.

However, floating point classification functions are easy to emulate on MSVC
(there has been a _fpclass() function for years), and that is what I have done.

I think we should try to avoid introducing gratuitous dependencies on such
"bleeding edge" language/library features, or provide workarounds. After all,
Win XP 32/MSVC 2003 is still a "Tier 1" platform for Qt 4.5, and MSVC 2005
for Qt 4.7, so why hinder platform portability without necessitation?

Thank you, and happy holidays!

Martin
Reply | Threaded
Open this post in threaded view
|

Re: HOWTO: Compiling LibreCAD with Visual Studio 2003 (and Qt 4.3.1 ...)

dxli
Hi Martin,

Please note that the pull request you sent is for an old "ellipse" branch instead of "master" branch of my repository, and it may explain why the pull request can not be applied cleanly.

try something like:

$ git checkout -f -b dli dli/master
(a local dli branch)
$ git merge master
(if it doesn't merge cleanly, need to fix it here)
$ git push -u origin dli:for-upstream
(this will push dli branch to a for-upstream branch in your github repository)

finally, send pull request to my master branch from your for-upstream branch

I tend to actively adapt to C++11. The reason: Qt5 will be C++11, and we have no intention to hold back everything for Windows compiler, as windows version of Qt-creator can be used for windows.

Thanks,

Dongxu

On Fri, Dec 30, 2011 at 8:49 AM, tin-pot [via LibreCAD] <[hidden email]> wrote:
Hi Dongxu,

thank you for the help on Git! I'll try it out soon.

dxli wrote
std::isnormal() is used to verify the number is not zero (of cause, not
NAN/INF). We use it to tell the difference between ellipse arc and whole
ellipses. For example, an ellipse arc has start/end angles, if both are set
to be exactly zero ( isnormal() = false), we treat the ellipse arc as an
whole ellipse. This is different from an whole range arc, because an arc
from 0 to 2 Pi will still have a start/end point, while a whole ellipse has
no start/end point.
I see. I just wondered if a simple comparison to zero wouldn't do the
job easier. Or, even easier - and safer - have a three-valued orientation
flag (CW arc, CCW arc, full turn); this would mirror the situation with
circular arcs/circles.

dxli wrote
I suppose std::isnormal() is C++ standard, we just have to figure out how
to use it in windows.
Well, kind of: AFAIK it was first specified in C99 (ISO 9899:1999) and then
adopted in <cmath> of C++11 (ISO 14882:2011). I don't know how
common C++11 is supported today - current MSVC versions up to 2010
obviously don't care.

However, floating point classification functions are easy to emulate on MSVC
(there has been a _fpclass() function for years), and that is what I have done.

I think we should try to avoid introducing gratuitous dependencies on such
"bleeding edge" language/library features, or provide workarounds. After all,
Win XP 32/MSVC 2003 is still a "Tier 1" platform for Qt 4.5, and MSVC 2005
for Qt 4.7, so why hinder platform portability without necessitation?

Thank you, and happy holidays!

Martin



If you reply to this email, your message will be added to the discussion below:
http://librecad.1049103.n5.nabble.com/HOWTO-Compiling-LibreCAD-with-Visual-Studio-2003-and-Qt-4-3-1-tp5108768p5110049.html
To start a new topic under LibreCAD-dev, email [hidden email]
To unsubscribe from LibreCAD-dev, click here.
NAML



--
Dongxu Li, Ph.D.
Reply | Threaded
Open this post in threaded view
|

Re: HOWTO: Compiling LibreCAD with Visual Studio 2003 (and Qt 4.3.1 ...)

tin-pot
dxli wrote
Please note that the pull request you sent is for an old "ellipse" branch
instead of "master" branch of my repository, and it may explain why the
pull request can not be applied cleanly.
Huh? Are you sure that said request is from me? I did not issue a pull request,
at least not intentionally (my working copy does not know about any other
upstream repositories yet, so this is improbable). Thanks for your patient
Git support, though!

dxli wrote
I tend to actively adapt to C++11. The reason: Qt5 will be C++11, and we
have no intention to hold back everything for Windows compiler, as windows
version of Qt-creator can be used for windows.
It seems that Qt 4.8 is already moving into that direction.

http://labs.qt.nokia.com/2011/05/26/cpp0x-in-qt/

If LibreCAD switches to Qt5 and thus doesn't support some compilers, that
would be fine with me. I _do_ know that VC 7.1 is somewhat outdated :-)
That would be a good time and reason to scrap MS and move over to BSD
and gcc (or llvm) ...

Greetings
Martin

Reply | Threaded
Open this post in threaded view
|

Re: HOWTO: Compiling LibreCAD with Visual Studio 2003 (and Qt 4.3.1 ...)

Rallaz
A good manual for GIT:
   http://www-cs-students.stanford.edu/~blynn/gitmagic/book.pdf

Online version, other formats, translations, source code, etc.
   http://www-cs-students.stanford.edu/~blynn/gitmagic/
Reply | Threaded
Open this post in threaded view
|

Re: HOWTO: Compiling LibreCAD with Visual Studio 2003 (and Qt 4.3.1 ...)

dxli
In reply to this post by tin-pot
Hi Martin,

You are right. The said pull request is from another developer.

Another way to understand LibreCAD source code, to go through our bug/feature request trackers. if you find something interesting, have a look at how we fixed/implemented stuff. We usually keep commit numbers within tracker comment.

Thanks,

Dongxu

On Fri, Dec 30, 2011 at 11:09 AM, tin-pot [via LibreCAD] <[hidden email]> wrote:
dxli wrote
Please note that the pull request you sent is for an old "ellipse" branch
instead of "master" branch of my repository, and it may explain why the
pull request can not be applied cleanly.
Huh? Are you sure that said request is from me? I did not issue a pull request,
at least not intentionally (my working copy does not know about any other
upstream repositories yet, so this is improbable). Thanks for your patient
Git support, though!

dxli wrote
I tend to actively adapt to C++11. The reason: Qt5 will be C++11, and we
have no intention to hold back everything for Windows compiler, as windows
version of Qt-creator can be used for windows.
It seems that Qt 4.8 is already moving into that direction.

http://labs.qt.nokia.com/2011/05/26/cpp0x-in-qt/

If LibreCAD switches to Qt5 and thus doesn't support some compilers, that
would be fine with me. I _do_ know that VC 7.1 is somewhat outdated :-)
That would be a good time and reason to scrap MS and move over to BSD
and gcc (or llvm) ...

Greetings
Martin




If you reply to this email, your message will be added to the discussion below:
http://librecad.1049103.n5.nabble.com/HOWTO-Compiling-LibreCAD-with-Visual-Studio-2003-and-Qt-4-3-1-tp5108768p5110319.html
To start a new topic under LibreCAD-dev, email [hidden email]
To unsubscribe from LibreCAD-dev, click here.
NAML



--
Dongxu Li, Ph.D.
Reply | Threaded
Open this post in threaded view
|

Re: HOWTO: Compiling LibreCAD with Visual Studio 2003 (and Qt 4.3.1 ...)

R. van Twisk
Administrator
In reply to this post by tin-pot
Martin,

I have modified the script to compile LibreCAD under windows a bit
so it will work with a stock Qt SDK and Stock boost installation.

Is it possible for you to checkout this code later this week and see if
it still works in Visual Studio? 

thanks!

Regards,
Ries van Twisk


On Dec 30, 2011, at 11:09 AM, tin-pot [via LibreCAD] wrote:

dxli wrote
Please note that the pull request you sent is for an old "ellipse" branch
instead of "master" branch of my repository, and it may explain why the
pull request can not be applied cleanly.
Huh? Are you sure that said request is from me? I did not issue a pull request,
at least not intentionally (my working copy does not know about any other
upstream repositories yet, so this is improbable). Thanks for your patient
Git support, though!

dxli wrote
I tend to actively adapt to C++11. The reason: Qt5 will be C++11, and we
have no intention to hold back everything for Windows compiler, as windows
version of Qt-creator can be used for windows.
It seems that Qt 4.8 is already moving into that direction.

http://labs.qt.nokia.com/2011/05/26/cpp0x-in-qt/

If LibreCAD switches to Qt5 and thus doesn't support some compilers, that
would be fine with me. I _do_ know that VC 7.1 is somewhat outdated :-)
That would be a good time and reason to scrap MS and move over to BSD
and gcc (or llvm) ...

Greetings
Martin




If you reply to this email, your message will be added to the discussion below:
http://librecad.1049103.n5.nabble.com/HOWTO-Compiling-LibreCAD-with-Visual-Studio-2003-and-Qt-4-3-1-tp5108768p5110319.html
To start a new topic under LibreCAD, email [hidden email]
To unsubscribe from LibreCAD, click here.
NAML

Reply | Threaded
Open this post in threaded view
|

Re: HOWTO: Compiling LibreCAD with Visual Studio 2003 (and Qt 4.3.1 ...)

dxli
Hi Kryzh,

First, you need boost and muparser. muparser must be compiled with msvc.

Please provides more details then.

Regards,

dxli
Reply | Threaded
Open this post in threaded view
|

Re: HOWTO: Compiling LibreCAD with Visual Studio 2003 (and Qt 4.3.1 ...)

dxli
I tried again with visual studio 2010, added some fixes for msvc here:

https://github.com/dxli/LibreCAD/tree/msvc

However, I still have no idea about this error as Martin found:

at line 316 of file:

https://github.com/LibreCAD/LibreCAD/blob/master/libraries/jwwlib/src/jwwdoc.h

basically, msvc complains that more than one overloaded functions matches:

std::ofstream << (double) x;

msvc complains that it could match both of the following:

std::ofstream << double
std::ofstream << long double

looks like msvc should have "long double" and "double" both as 8-byte floating point.

it's very puzzling to me.
Reply | Threaded
Open this post in threaded view
|

Re: HOWTO: Compiling LibreCAD with Visual Studio 2003 (and Qt 4.3.1 ...)

dxli
I managed to build LibreCAD (the msvc branch) with Visual Studio 2010 (with Qt plugin).

I used Qt plugin to read in the qmake project file: librecad.pro
After that, some settings still have to be modified manually. LibreCAD builds and run without an issue.

Download the latest Qt for Windows (not QtSDK with mingw);

1, you need boost downloaded to a folder, the default setting is c:\boost\boost_1_49_0\
2, you need muparser 2.2.2 downloaded and built with MSVC 2010 as release DLL and static lib, you can keep the muparser_v2_2_2 in the LibreCAD folder or other place at your choice;
3, for boost and muparser, make sure include folder is set in project properties->configuration properties-> VC++ Properties-> Include directories; for muparser, make sure the library directories are set to include the lib directory under muparser source folder.
4, in project properties->configuration properties->Linker->Additional dependency,
change muparser.lib to muparser32.lib

if you still get header file errors, double check step 4.

if you get shared library error, you need to set PATH in windows to include the muparser dll within PATH ( the lib folder under muparser source folder).

Please help us improve msvc support and help building our building document.

thanks,

dxli