This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 175374 - CMakeLists.txt doing all work in a subdir
Summary: CMakeLists.txt doing all work in a subdir
Status: CLOSED FIXED
Alias: None
Product: cnd
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker with 3 votes (vote)
Assignee: Alexander Simon
URL:
Keywords:
Depends on:
Blocks: 187623 192728
  Show dependency tree
 
Reported: 2009-10-24 19:55 UTC by chunkyks
Modified: 2012-03-26 07:30 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments
svn status output after netbeans configured my project via cmake (1.53 KB, text/plain)
2009-10-24 19:55 UTC, chunkyks
Details

Note You need to log in before you can comment on or make changes to this bug.
Description chunkyks 2009-10-24 19:55:14 UTC
In nb6.8 [C/C++ build 200910212001], I was overjoyed to see that it now recognises CMakeLists.txt as a "configure" build
script.

The problem with the default cmake behaviour [building from the dir that contains CMakeLists.txt] is that cmake spreads
filesystem cruft throughout the entire source checkout. CMake has excellent behaviour when run from a "build"-type
subdir, and I would love that to be possible via netbeans.

Path to reproduce [netbeans]:
0) Download and install 6.8 beta C++ bundle: netbeans-6.8beta-ml-cpp-linux.sh
1) svn co svn://svn.icculus.org/obdgpslogger/trunk obdgpslogger
2) Open Netbeans, click on new project. Choose C/C++ project with existing sources
3) Specify the top-level svn checkout created in step 1
4) Step through the rest of the process, both automatic and manual configuration do the same thing from here
5) Look at the filesystem [with svn status or similar] [I will attach a sample after submitting this bug]

Normal build instructions [from my website]:
1) svn co svn://svn.icculus.org/obdgpslogger/trunk obdgpslogger
2) cd obdgpslogger; mkdir build; cd build
3) cmake ..
4) make

At no point am I offered an option to do all work in a separate directory when netbeans does this for me. Netbeans does
update svn:ignore on each directory so that the final build products will be ignored, but it's not set for any
intermediary build products and CMake build cruft.

My project builds on OpenSolaris, Linux, Cygwin, OSX, on all architectures I've tried - this same behaviour should be
manifestable on just about any system.

I believe that actual 'configure' scripts typically have the same ability [to put all build products, intermediary and
final, into a separate subdir] - perhaps this is something common to any build systems that netbeans will be able to use?
Comment 1 chunkyks 2009-10-24 19:55:59 UTC
Created attachment 90052 [details]
svn status output after netbeans configured my project via cmake
Comment 2 chunkyks 2009-11-10 11:04:31 UTC
Changing to all platforms - I see the same behaviour on systems other than the original one I tried.
Comment 3 gbullock 2010-06-16 00:37:04 UTC
I share the joy at seeing support for CMakeLists.txt.  Very cool.  Good job, team!

While I also share your wish that NetBeans build such projects in a subdirectory, instead of in the source folder, I would prefer that the build subdirectory have a more specific name, based on the currently selected configuration and possibly the toolcollection and/or other developmenthost.  Thus, I would like to see NetBeans use build instructions something like:

1) cd <projectfolder>; 
2) mkdir build; cd build
3) mkdir <configuration>; cd <configuration>
4) mkdir <toolcollection>-<developmenthost>; cd <toolcollection>-<developmenthost>
5) cmake ../../..
6) make

Any variation of this would be most acceptable to me.  It would probably be best for NetBeans to essentially mirror the build commands it follows for "managed" projects.

I recognize that, at present, the notions of <configuration>, <toolcollection>, and <developmenthost> are less clear for cMake-based projects than they are for managed Makefile projects, but I'll post a separate feature request that the <configuration> get passed to CMake on its command line:

5) cmake -DCMAKE_BUILD_TYPE=<configuration> ../../..

along with a few other relevant options.
Comment 4 CMoH 2010-09-07 12:04:21 UTC
CMake developers actually recommend this usage mode. I have found it to be better supported and having a lot of advantages as opposed to in-tree build.

Besides that, using in-tree cmake with netbeans is currently a non-working scenario together with version control, since all the build artefacts are presented for SVN checkin.
Comment 5 CMoH 2010-11-13 02:45:29 UTC
Bah - nothing after the latest updates. Unfortunately this cmake plugin is unusable with a version control. All new files created by cmake in the same dir are treated by the SVN plugin as "new" files, and it wants to commit them all.

Back to KDevelop :)
Comment 6 soldatov 2010-11-13 07:58:03 UTC
Other same enhancement: http://netbeans.org/bugzilla/show_bug.cgi?id=187623
Comment 7 Alexander Simon 2010-11-30 17:23:44 UTC
fixed, change set:
http://hg.netbeans.org/cnd-main/rev/33e822320dd9

Now IDE can run configure in subfolder for:
- "configure" shell script
- "CMakeLists.txt" cmake script
- "*.pro" qmake script
Comment 8 Quality Engineering 2010-12-01 06:40:58 UTC
Integrated into 'main-golden', will be available in build *201012010001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/33e822320dd9
User: Alexander Simon <alexvsimon@netbeans.org>
Log: fixed Bug #175374 CMakeLists.txt doing all work in a subdir
Comment 9 chunkyks 2010-12-01 08:27:33 UTC
Awesome, it works great. Thank-you very much

Should that behaviour be made the default? I first ran this with "automatic", and it spread the same cruft through the sub dir

I suspect that the best thing to do would be to make cmake and qmake work in a subdir by default, but make autoconf work in the same level by default. Either way, I'll close this as resolved and open a new bug for discussion.