The first question is, what is the remote host operation system?
("uname  -a" on Linux, "uname -X" on Solaris)

If you launch IDE with additional command line options
-J-Dcnd.remote.logger.level=0 -J-Dnativeexecution.support.logger.level=0
and attach the IDE log, this will also help me to understand what's going wrong.

Created attachment 114789 [details]
Log file

Remote OS is:

[mkulin@cms-build-3 ~]$ uname -a
Linux cms-build-3 2.6.32-71.el6.x86_64 #1 SMP Fri May 20 03:51:51 BST 2011 x86_64 x86_64 x86_64 GNU/Linux
[mkulin@cms-build-3 ~]$ lsb_release -a
LSB Version:    :core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID: CentOS
Description:    CentOS Linux release 6.0 (Final)
Release:        6.0
Codename:       Final

Created attachment 114790 [details]
"Create new C/C++ project from existing prj" logs

Thank you for additional information.
It seems that the remote agent that ensures file delivery quit unexpectedly.
Could you add two more parameters and attach (or send me) IDE log
-J-Dcnd.rfs.preload.trace=1
-J-Dcnd.rfs.controller.trace=1
Thank you!

Created attachment 114877 [details]
Extended logs

Thank you; may I ask you for a little more. 
It seems that the part of the trace I need has got into the IDE output window instead of the log (most likely there are lines RFS_P in it).
Could you send it as well?

Created attachment 114925 [details]
IDE output

I was able to save only these traces from IDE (see attached).
The output window closes too fast and unfortunately I observe the issue http://statistics.netbeans.org/analytics/exception.do?id=556554

After attached traces I see this one:
-------------------------------------------------
CMake Error: Error in cmake code at
/home/mkulin/.netbeans/remote/cms-build-3/mak-Windows-x86/D/Work/CMS/sources/trunk/CMakeLists.txt:1:
Parse error.  Expected a command name, got unquoted argument with text "".
-- Configuring incomplete, errors occurred!
-------------------------------------------------

(In reply to comment #8)
> The output window closes too fast
You probably invoked "clean and build" or "run"; 
could try just "clean" (from Project Pane context menu)? 
The effect (the bug) should be the same, but there shouldn't be window reuse in thus case.

Created attachment 114937 [details]
test for auto copy

Here is yet another experiment that could shed some light on the problem.
The attached are two files, a .c file and .sh file, which test auto copy.
Could you please save the attached .zip and do the following and send me the console output.

cd /var/tmp/dlight_mkulin/db6ce52e/tools

unzip rfs_test_env.zip

gcc -fPIC -D_GNU_SOURCE -Wreturn-type -Wimplicit -Werror -std=c99 -m32 -DTRACE=1 rfs_test_env.c  -o Linux-x86/rfs_test_env

gcc -fPIC -D_GNU_SOURCE -Wreturn-type -Wimplicit -Werror -std=c99 -m64 -DTRACE=1 rfs_test_env.c  -o Linux-x86_64/rfs_test_env

sh ./rfs_test_env.sh

(In reply to comment #10)
> Created attachment 114937 [details]
> test for auto copy
> 
> Here is yet another experiment that could shed some light on the problem.
> The attached are two files, a .c file and .sh file, which test auto copy.
> Could you please save the attached .zip and do the following and send me the
> console output.
> 
> cd /var/tmp/dlight_mkulin/db6ce52e/tools
> 
> unzip rfs_test_env.zip
> 
> gcc -fPIC -D_GNU_SOURCE -Wreturn-type -Wimplicit -Werror -std=c99 -m32
> -DTRACE=1 rfs_test_env.c  -o Linux-x86/rfs_test_env
> 
> gcc -fPIC -D_GNU_SOURCE -Wreturn-type -Wimplicit -Werror -std=c99 -m64
> -DTRACE=1 rfs_test_env.c  -o Linux-x86_64/rfs_test_env
> 
> sh ./rfs_test_env.sh

I did the test. Please, check output:

[mkulin@cms-build-3 tools]$ sh rfs_test_env.sh 
rfs_test_env.sh: line 3: [: : integer expression expected
486788993 #RFS_P[15813]:  started in /var/tmp/dlight_mkulin/db6ce52e/tools
488128114 #RFS_P[15813]: test_env ON
488218842 #RFS_P[15813]: RFS startup (1) my dir: /var/tmp/dlight_mkulin/db6ce52e/tools/
488236628 #RFS_P[15813]: open /tmp/open 0
488491671 #RFS_P[15813]: open /tmp/open -> -1
488499780 #RFS_P[15813]: open64 /tmp/open64 0
488714711 #RFS_P[15813]: open64 /tmp/open64 -> -1
488721762 #RFS_P[15813]: fopen /tmp/fopen r
489024251 #RFS_P[15813]: fopen /tmp/fopen -> 0
489041777 #RFS_P[15813]: fopen64 /tmp/fopen64 r
489071304 #RFS_P[15813]: fopen64 /tmp/fopen64 -> 0
489079502 #RFS_P[15813]: RFS shutdown (1)
open OK
open64 OK
fopen OK
fopen64 OK

(In reply to comment #9)
> (In reply to comment #8)
> > The output window closes too fast
> You probably invoked "clean and build" or "run"; 
> could try just "clean" (from Project Pane context menu)? 
> The effect (the bug) should be the same, but there shouldn't be window reuse in
> thus case.

It seems that I was not clear about what I am doing. Sorry, that you need to make an assumptions.

Each time I reproduce the issue just doing "new project" -> C/C++ -> "Project with existing sources". Than I choose Custom configuration mode and on the next screen select "Run configure script in subfolder". That's all.

After that NetBeans (if I am right) try to synchronize sources with remote side and execute 'cmake ..........' etc.

P.S. I need also to say, that if perform "Upload" manually (from context menu) it uploads something feasible, I mean that content of some files is correct. But there is another problem - not all files are uploaded correctly, but this is another story I think... :) (I would like to focus on it later.)

Created attachment 114953 [details]
IDe output after "Clean & Build"

Finally, I think, I got what you expect. After execution "Clean and build" IDE output can be saved, please, check attached.

The path 
/home/mkulin/.netbeans/remote/cms-build-3/mak-Windows-x86/D/Work/CMS/sources/trunk/build_cms
defined in "Run Configure Script in Subfolder"

Hi,

Any news on that?

Thank you for sending me the log.
As far as I understand, the file D:/Work/CMS/sources/trunk/build_cms/Makefile
is absent on your local disk, is that true?

Could I ask you to create a very simple project (e.g. Samples/Arguments or Welcome) and try building it on the same remote host. As I understand, it will build OK, is that correct?

From the log I see that D:/Work/CMS/sources/trunk/build_cms/Makefile 
is absent. I guess in your project properties, in Build > Make section,
"Build Command" is incorrect: it should be cmake instead of Make.
Is my assumption correct?

Created attachment 118179 [details]
A sample CMake project I used for test purposes

I tried to test creation of a cmake based project from existing source from Windows to Linux and from Linux to Linux and found no issues so far. Need additional information no proceed.

I finally was able to got an issue that was initially described:

CMakeFiles/Makefile.cmake:1:
Parse error.  Expected a command name, got unquoted argument with text "".

Unfortunately I haven't wrote down the exact sequence of steps.

But what I know for sure is that until I didn't build locally prior than creating NetBeans project targeted to remote host, everything went smoothly.

But if I call cmake locally first, then launch NetBeans and create project targeted to remote host, I get the following error when creating project:

CMake Error: The current CMakeCache.txt directory /home/vk***/.netbeans/remote/***/***-Linux-x86_64/home/vk***/testdata/cmake_hello/CMakeCache.txt is different than the directory /home/vk***/testdata/cmake_hello where CMackeCache.txt was created. This may result in binaries being created in the wrong place. If you are not sure, reedit the CMakeCache.txt

CMake Error: The source "/home/vk***/.netbeans/remote/***/***-Linux-x86_64/home/vk***/testdata/cmake_hello/CMakeLists.txt" does not match the source "/home/vk***/testdata/cmake_hello/CMakeLists.txt" used to generate cache.  Re-run cmake with a different source directory.

Some attempt to build project after that led to the error like one in initial description:
Parse error.  Expected a command name, got unquoted argument with text "".

I need to investigate this better.

We have 2 problems here.

1. In a CMake based project from existent code, build command is standard  
${MAKE} -f Makefile"

But makefiles should be regenerated for each host. This is not auto-copy problem, shared mode will face it as well.

2. CMakeCache.txt prevents makefiles regeneration , so it should not be copied to remote host (or, in shared mode, should be deleted).


Workarounds are:

1. Change build command to 
sh -c "cmake . && ${MAKE} -f Makefile"

2. Before building on remote host, remove CMakeCache.txt. If you already tried to build on remote host, remove CMakeCache.txt there (the most simple way to do so is to invoke a terminal via a black button on output window tool bar, then your cwd is exactly where remote CMakeCache.txt resides).

The issue is not reproduced on a newest build, currently CMakeCache is not copied to a remote host