Thu, 01/21/2010 - 08:41
1. Binaries to be placed into subdirs per Visual Studio version
That is, instead of ./win32/bin, ./win32/obj/ to place /win32/vc8/bin, ./win32/vc9/bin,...
Values: vc7.1 (VS2003), vc8 (VS2005), vc9 (VS2008), vc10 (Dev 10)
Benefit: On workstations where compilation (and further execution) by different VS versions is required this allows to avoid manual temporary directory renaming
This approach is used by Qt, TBB, etc.
2. Name Debug libraries (*.dll and *.lib) adding a suffix (e.g. *d, like TKerneld.dll or *_debug, like TKGeom3d_debug.dll) and place into one directory (win32/*/bin or /lib).
Benfits:
- reduced maintenance costs on environment files used when starting Visual Studio or launch scripts (which currently have to set path to different directories)
- avoided annoyance of exiting and restarting Visual Studio when switching between Debug and Release modes (which can be time consuming for large projects)
- avoided probability of mix of Debug and Release libraries during testing (i.e. currently you might test your app using debug libraries by mistake to find out that when you ship release libs your customer will discover an error you never met)
This approach is used by MSFT (msvcr80.dll or msvcr80d.dll), Qt, TBB, etc.
This approach will require creation of subdirs in obj directory mode (e.g. ./win32/vc8/obj/debug and ./release)
We made some preliminary discussions with the OCC team on this last year but did not close. So comments from all parties (OCC and community) will be appreciated.
Thanks,
Roman
Thu, 01/21/2010 - 10:40
Hi Roman,
I completely agree with your post.
1. I use to develop with VS2003 and VS2008. I already manually created win32/vc7.1 and win32/vc9 folders where I place the *.lib a *.dll files. This manual operation requires that I copy/paste the win32/bin and win32/lib to this folders each time I recompile OCC. It's quite confusing, I'm sometime lost, with a high risk to make a mistake when moving this files. The question I'm often asking myself: am I sure that the DLL I'm trying to link to my project is the good one?
+1 for me.
2. I don't use to compile OCC in Debug mode, so this part of your post is a bit far from my needs. But I'm quite convinced by your arguments.
Best Regards,
Thomas
Thu, 01/21/2010 - 11:50
Again, using a cross platform make system would be nicer, and custom configurations would be possible. For example, I don't want to install TCL only to compile WOK or DRAW, so I usually exclude it from the project.
Another advantage would be a simpler multi-platform and multi-project management (ie. 32 bit and 64 bit).
CMake is good, but there are many others.
BTW : this is a point of the yet un-answered wish list :)
Thu, 01/21/2010 - 12:15
Hi, I do not care about compilation with VS, but would love to see improvements from
http://www.opencascade.org/org/community/osprojects/?project_id=127
merged upstream, in particular the split of the inc/ directory.
It would also be really, really helpful to add a prefix to all headers, say Occ/ for instance.
This approach is used by Qt, X11 and many others ;-)
I can help if this work has a chance to be considered.
Fri, 01/22/2010 - 03:28
Hi Roman, Hi All,
1. Personally, I rather use different OCC versions compiled with one compiler so this change doesn't really affect me a lot. However, I would still need a solution if I use the original and self compiled version (using the same compiler).
2. I think the most important thing is, how many developers/team/customers have already implemented their own solutions (hard links, directory renaming etc.) to cope with the situation. Renaming the dlls and libs might also mean rewriting the code if it explicitly refers to a dll at some point. I guess debug and release library had different names until OCC 5.0.(I guess) - so why did the OCC team change this?
3. My suggestion: I would really appreciate creation of a single solution file containing all OCC projects. The compilation on a multi-core processor is much faster.
Pawel
Fri, 01/22/2010 - 07:54
Hi Pawel, and all,
Thanks for adding your comments and new suggestions. Please keep them coming.
2. "I think the most important thing is, how many developers/team/customers have already implemented their own solutions (hard links, directory renaming etc.) to cope with the situation. Renaming the dlls and libs might also mean rewriting the code if it explicitly refers to a dll at some point. I guess debug and release library had different names until OCC 5.0.(I guess) - so why did the OCC team change this?"
- I ended up having a set of *.bat files which accept an argument (Release or Debug) depending on which the PATH variable is constructed (to include either win or wind). Anytime I have to use another mode I exit Studio, use another Windows shortcut (to call the launch script with the opposite mode). With having one dir, this switch (which takes about a minute) would not be required and the path could be added to system environment.
- Rewriting user's code would be limited to either modifying project files or compiled source files containing #pragma. Both are not effort-consuming I believe. However you thought led me to another one on how to facilitate linking with OCC libraries which is used in Intel TBB for instance. Whenever you #include a tbb header it automatically inserts pragma to force linking with required lib:
#if _MSC_VER
#if !__TBB_NO_IMPLICIT_LINKAGE
#ifdef _DEBUG
#pragma comment(lib, "tbb_debug.lib")
#else
#pragma comment(lib, "tbb.lib")
#endif
#endif
#endif
This way developers do not care at all about explicit specifying an import library. Such issues are often reported on this forum by OCC newbies. Perhaps the OCC team could also think of that.
- 5.0 ? I'm not sure this ever existed but I can wrong. And if you are correct then it would indeed be interesting to hear OCC reasoning.
3. This was announced in 6.3.1 Release Notes so it should likely appear in next public release.
Thanks again,
Roman
Fri, 01/22/2010 - 14:37
Hi Roman,
2. In fact, I have a very primitive (and unprofessional) way of coping with the problem - I rename the corresponding OCC lib/bin directories while the project is still open. This way, I don't have to restart the IDE and I can test multiple configurations without maintaining multiple project settings. Well, as I said very unprofessional but it works fine in my case...
I guess up to OCC 5.0 the library was delivered with a precompiled debug version of the dlls. It resided in libd/bind directories. I'm not sure whether the file names were different (*d.lib, *d.dll) or not...
Pawel
Sat, 02/13/2010 - 09:06
Re #3 - in OCCT.sln please provide Solution level folders, one for each module (Foundation Classes, Modeling Data, etc). This does not impact anything but a visual look - structured tree instead of flat list of projects.
Thanks,
Roman