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 203376 - C/C++ projects corrupt makefiles for other platforms even though it is aware those files should not be updated on the current platform
Summary: C/C++ projects corrupt makefiles for other platforms even though it is aware ...
Status: RESOLVED FIXED
Alias: None
Product: cnd
Classification: Unclassified
Component: Project (show other bugs)
Version: 7.0
Hardware: All All
: P3 normal with 1 vote (vote)
Assignee: Alexander Simon
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-09 02:33 UTC by swpalmer
Modified: 2015-06-05 02:38 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description swpalmer 2011-10-09 02:33:16 UTC
Product Version = NetBeans IDE Dev (Build 201110050601)
Operating System = Mac OS X version 10.7.1 running on x86_64
Java; VM; Vendor = 1.6.0_26
Runtime = Java HotSpot(TM) 64-Bit Server VM 20.1-b02-383

Make a C++ project on Linux. 
Rename the project configurations Debug_Linux and Release_Linux.
Check it in to a VCS so you can easily see what changes are made to the files.
Open it on OS X.
Add two new configurations, name them Debug_OS_X and Release_OS_X.
Make Release_OS_X the current configuration
Build it.
NB will complain:

  Makefiles for the following configuration(s) were not generated due to a mismatch between the current build host platform "Mac OS X" and the build platform(s) in the  configuration(s):

  Debug_Linux  [build platform: Linux x86]
  Release_Linux  [build platform: Linux x86]

  The makefiles will automatically get generated next time the project is opened on those platforms.

dismiss all of those dialogs and allow the build to finish.

Check the project files for changes:

e.g. svn diff Makefile-variables.mk 
Index: Makefile-variables.mk
===================================================================
--- Makefile-variables.mk	(revision 59356)
+++ Makefile-variables.mk	(working copy)
@@ -6,54 +6,38 @@
 CND_BASEDIR=`pwd`
 CND_BUILDDIR=build
 CND_DISTDIR=dist
 # Debug_Linux configuration
-CND_PLATFORM_Debug_Linux=GNU-Linux-x86
-CND_ARTIFACT_DIR_Debug_Linux=dist/Debug_Linux/GNU-Linux-x86
+CND_PLATFORM_Debug_Linux=GNU-MacOSX
+CND_ARTIFACT_DIR_Debug_Linux=dist/Debug_Linux/GNU-MacOSX
 CND_ARTIFACT_NAME_Debug_Linux=libKayakTSBroadcast.so
-CND_ARTIFACT_PATH_Debug_Linux=dist/Debug_Linux/GNU-Linux-x86/libKayakTSBroadcast.so
-CND_PACKAGE_DIR_Debug_Linux=dist/Debug_Linux/GNU-Linux-x86/package
-CND_PACKAGE_NAME_Debug_Linux=libKayakTSBroadcastNative.so.tar
-CND_PACKAGE_PATH_Debug_Linux=dist/Debug_Linux/GNU-Linux-x86/package/libKayakTSBroadcastNative.so.tar
+CND_ARTIFACT_PATH_Debug_Linux=dist/Debug_Linux/GNU-MacOSX/libKayakTSBroadcast.so
+CND_PACKAGE_DIR_Debug_Linux=dist/Debug_Linux/GNU-MacOSX/package
+CND_PACKAGE_NAME_Debug_Linux=libKayakTSBroadcastNative.dylib.tar
+CND_PACKAGE_PATH_Debug_Linux=dist/Debug_Linux/GNU-MacOSX/package/libKayakTSBroadcastNative.dylib.tar
...

As you can see it is modifying the Linux project config on OS X
NB should be more platform aware and do what it says - wait until the projects are opened on the other platform to modify that platforms project settings.

The configurations.xml file keeps track of the platforms for each project config, but then that info is ignored and all Makefiles are updated as if they are for the current platform.
This may appear to work as each time a project is opened in NB on any platform all of the makefiles change to work with that platform, but if you check in the make files and expect them to build outside of NB, everything is broken.
Comment 1 Leonid Lenyashin 2011-10-10 09:04:10 UTC
Sasha,please evaluate the bug first of all.
Comment 2 Alexander Simon 2011-10-10 15:47:50 UTC
(In reply to comment #0)
> Check it in to a VCS so you can easily see what changes are made to the files.
Please provide more info about ignored folders.
Did you add anything in ignored pattern?

Probably this patterns (hg syntax of .hgignore):
/build$
/dist$
/private$
\.dep\.inc$
\.make\.state\..*$
are candidates to be ignore.
Comment 3 swpalmer 2011-10-10 17:17:15 UTC
That's not at all relevant to the problem!
The files in question will be in the nbproject folder.  They are the platform specific makefiles.  Just don't ignore them.
Look in the file I wrote about "Makefile-variables.mk"
When the configuration.xml file has configurations for multiple platforms, e.g. Mac and Linux, the Makefile-variables.mk file is re-written for ALL configurations, not just the configurations for the current platform.  That is the problem.
Comment 4 Alexander Simon 2011-10-10 18:26:00 UTC
(In reply to comment #3)
> That's not at all relevant to the problem!
Try to add /private$ in ignore list and you will see absolutely different IDE behavior.
Comment 5 swpalmer 2011-10-10 18:50:29 UTC
This has NOTHING TO DO WITH VERSION CONTROL.
This has NOTHING TO DO WITH FILES IN nbproject/private

Seriously! If you aren't even going to spend the slightest amount of time even trying to understand the problem, why should I bother reporting it!

Re-read the original problem report.  I am done.
Comment 6 swpalmer 2011-10-10 19:00:32 UTC
For the record the nbproject/private folder is NOT checked in. Nothing in that folder is ever shared between the Linux and Mac machines involved.
Comment 7 swpalmer 2011-10-10 19:02:58 UTC
I just noticed that files of the same name are in the private folder. These are NOT the files i am talking about.   The files with the problem are in not private files, they are in the nbproject folder itself.
Comment 8 Alexander Simon 2011-10-10 19:40:21 UTC
(In reply to comment #5)

> Seriously! If you aren't even going to spend the slightest amount of time even
> trying to understand the problem, why should I bother reporting it!
Let's I try to explain "sharing" model of C/C++ projects.
1. Sharing by file system (for example by home folder).
In this case all project metadata shared (nbproject/* and nbproject/private/*).
Folder nbproject/pivate/* contains user/platform/tools dependent information and cannot be shared between users/companies.
2. Sharing by VCS.
In this case /private/* folders should not be shared.

As I understand you use sharing project by file system and does not exclude /private/* folder from sharing.
I exactly understand the issue you talk about (issue description is good).
I want to understand purpose of sharing project. It help me understand real user needs.
Comment 9 swpalmer 2011-10-10 20:05:13 UTC
"As I understand you use sharing project by file system and does not exclude
/private/* folder from sharing."

NO.

As I have already stated. See comment #6,  The "private" folder is NOT shared.
I am doing what you have listed as #2, Sharing only the public stuff via VCS.

Please try again.
Comment 10 Quality Engineering 2011-10-11 14:11:33 UTC
Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/3114ab1180a9
User: Alexander Simon <alexvsimon@netbeans.org>
Log: fixed Bug #203376 C/C++ projects corrupt makefiles for other platforms even though it is aware those files should not be updated on the current platform
Comment 11 swpalmer 2011-10-12 01:01:54 UTC
Much appreciated.

Thanks!
Comment 12 swpalmer 2012-02-21 21:28:39 UTC
It seems this is fixed for OS X.. I.e. When use OS X it doesn't mess up my Linux makefiles.  But it is still a problem on Linux.. NB 7.1 on Linux just re-wrote all of the OS_X variables in my nbproject/Makefile-variables.mk file and similarly trashed the OS X Makefiles.
Comment 13 Alexander Simon 2012-02-22 05:53:16 UTC
Please, attach diff of nbproject/Makefile-variables.mk.
Comment 14 swpalmer 2012-02-22 20:39:48 UTC
diff -r 1035c7ae92b2 KayakNative/nbproject/Makefile-variables.mk
--- a/KayakNative/nbproject/Makefile-variables.mk	Tue Feb 21 16:16:09 2012 -0500
+++ b/KayakNative/nbproject/Makefile-variables.mk	Tue Feb 21 16:29:10 2012 -0500
@@ -23,21 +23,21 @@
 CND_PACKAGE_NAME_Release_Linux=libKayakNative.so.tar
 CND_PACKAGE_PATH_Release_Linux=dist/Release_Linux/GNU-Linux-x86/package/libKayakNative.so.tar
 # Debug_OS_X configuration
-CND_PLATFORM_Debug_OS_X=GNU-MacOSX
-CND_ARTIFACT_DIR_Debug_OS_X=dist/Debug_OS_X/GNU-MacOSX
-CND_ARTIFACT_NAME_Debug_OS_X=libKayakNative.dylib
-CND_ARTIFACT_PATH_Debug_OS_X=dist/Debug_OS_X/GNU-MacOSX/libKayakNative.dylib
-CND_PACKAGE_DIR_Debug_OS_X=dist/Debug_OS_X/GNU-MacOSX/package
-CND_PACKAGE_NAME_Debug_OS_X=libKayakNative.dylib.tar
-CND_PACKAGE_PATH_Debug_OS_X=dist/Debug_OS_X/GNU-MacOSX/package/libKayakNative.dylib.tar
+CND_PLATFORM_Debug_OS_X=GNU-Linux-x86
+CND_ARTIFACT_DIR_Debug_OS_X=dist/Debug_OS_X/GNU-Linux-x86
+CND_ARTIFACT_NAME_Debug_OS_X=libKayakNative.so
+CND_ARTIFACT_PATH_Debug_OS_X=dist/Debug_OS_X/GNU-Linux-x86/libKayakNative.so
+CND_PACKAGE_DIR_Debug_OS_X=dist/Debug_OS_X/GNU-Linux-x86/package
+CND_PACKAGE_NAME_Debug_OS_X=libKayakNative.so.tar
+CND_PACKAGE_PATH_Debug_OS_X=dist/Debug_OS_X/GNU-Linux-x86/package/libKayakNative.so.tar
 # Release_OS_X configuration
-CND_PLATFORM_Release_OS_X=GNU-MacOSX
-CND_ARTIFACT_DIR_Release_OS_X=dist/Release_OS_X/GNU-MacOSX
-CND_ARTIFACT_NAME_Release_OS_X=libKayakNative.dylib
-CND_ARTIFACT_PATH_Release_OS_X=dist/Release_OS_X/GNU-MacOSX/libKayakNative.dylib
-CND_PACKAGE_DIR_Release_OS_X=dist/Release_OS_X/GNU-MacOSX/package
-CND_PACKAGE_NAME_Release_OS_X=libKayakNative.dylib.tar
-CND_PACKAGE_PATH_Release_OS_X=dist/Release_OS_X/GNU-MacOSX/package/libKayakNative.dylib.tar
+CND_PLATFORM_Release_OS_X=GNU-Linux-x86
+CND_ARTIFACT_DIR_Release_OS_X=dist/Release_OS_X/GNU-Linux-x86
+CND_ARTIFACT_NAME_Release_OS_X=libKayakNative.so
+CND_ARTIFACT_PATH_Release_OS_X=dist/Release_OS_X/GNU-Linux-x86/libKayakNative.so
+CND_PACKAGE_DIR_Release_OS_X=dist/Release_OS_X/GNU-Linux-x86/package
+CND_PACKAGE_NAME_Release_OS_X=libKayakNative.so.tar
+CND_PACKAGE_PATH_Release_OS_X=dist/Release_OS_X/GNU-Linux-x86/package/libKayakNative.so.tar
 #
 # include compiler specific variables
 #
Comment 15 Mr_and_Mrs_D 2012-04-19 16:27:40 UTC
Yes probably - I just now started using this feature (remote) so i am not too sure. What happens is that it builds correctly then it diplays the "Protocol error: killed" in red then it opens a new tab (in the output window) where it displays the RUN SUCCESSFUL notification - this is how it should be ?

Thanks for your time
Comment 16 Mr_and_Mrs_D 2012-04-19 16:35:36 UTC
Excuse me for the previous post - it was for another bug
Comment 17 swpalmer 2012-06-26 16:27:02 UTC
This issue persists with NB 7.2 On both Linux and Mac.
Comment 18 Maria Tishkova 2012-12-07 13:28:49 UTC
Will set target release to Next as we need to re-work our Makefile generation to support VCS
Comment 19 Maria Tishkova 2013-08-27 07:46:28 UTC
as new Makefiles generation is not implemented in this release, move this issue to the next release
Comment 20 swpalmer 2013-08-27 14:19:52 UTC
Three years and counting of constantly having to undo NetBeans breaking my projects... sigh.
Comment 21 Maria Tishkova 2013-08-27 19:08:15 UTC
I am really sorry you need to do this, but maybe creating your own Makefile would resolve this problem? I mean you could try to use Project from Existing sources not Application type project. ( we call them unmanaged - when you have your own Makefile or build script and managed - when you want IDE generate Makefile for you).

(In reply to swpalmer from comment #20)
> Three years and counting of constantly having to undo NetBeans breaking my
> projects... sigh.
Comment 22 Quality Engineering 2015-06-05 02:38:47 UTC
Integrated into 'main-silver', will be available in build *201506050001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/1b1e32784615
User: Alexander Simon <alexvsimon@netbeans.org>
Log: fixing Bug #203376 C/C++ projects corrupt makefiles for other platforms even though it is aware those files should not be updated on the current platform
-make configuration platform specific