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 168475 - Multi-platform support is unusable
Summary: Multi-platform support is unusable
Status: VERIFIED FIXED
Alias: None
Product: cnd
Classification: Unclassified
Component: Project (show other bugs)
Version: 5.x
Hardware: Macintosh All
: P2 blocker with 1 vote (vote)
Assignee: Thomas Preisler
URL:
Keywords:
: 168542 177884 178531 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-07-13 13:01 UTC by shiretu
Modified: 2010-01-26 09:31 UTC (History)
8 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
remote (77.86 KB, image/jpeg)
2009-10-28 05:24 UTC, Thomas Preisler
Details
local host (81.44 KB, image/jpeg)
2009-10-28 05:26 UTC, Thomas Preisler
Details

Note You need to log in before you can comment on or make changes to this bug.
Description shiretu 2009-07-13 13:01:54 UTC
Hello,

Maybe I'm expecting the wrong things from NetBeans... I'm trying to add several Debug/Release configurations for my 
c++ project for different platforms: FreeBSD, Linux and Mac OS X. 

Netbeans becomes totally unusable. If I close the NetBeans on Linux with Debug_LINUX configuration selected and I 
open the project in Mac OS X, it will not compile. It complains that the selected configuration is not compatible with the 
current operating system. Which is correct. But it also modifies something behind the scenes because I can't compile the 
project on linux anymore. Now, I try to select the correct configuration (Mac OS X in this example). Still no joy... All the 
link dependencies between projects are either absent or wrong (references wrong platform).

For all those different debug/release configuration I specifically select the correct platform in Project Properties->Build-
>Development Host (which is always localhost [XXXX], where XXXX is the operating system). 

Am I doing something wrong?

Thank you for your support
Comment 1 Thomas Preisler 2009-10-23 18:13:08 UTC
*** Issue 168542 has been marked as a duplicate of this issue. ***
Comment 2 Thomas Preisler 2009-10-23 18:18:35 UTC
Yes, this is a problem. This works correctly if you use remote development. Configurations can point to different
platform types and you can switch between the configurations and things works correctly, but you cannot no longer move
the project from platform to platform and have different configurations for the different platforms. The problem is
'local host' is generic and doesn't say what platform it was when you generated the project. Will see if I can come up
with a solution....
Comment 3 Thomas Preisler 2009-10-28 05:22:27 UTC
Problem:
When remote was introduced, the build platform property (called Platform) was overtaken by the Development Host
property. It works very well for remote configurations but when it is set to 'localhost', we loose information about
what platform it really is meant for and we always generate all the makefiles for the platform you are on (the local
host). It means you cannot have one configuration for Solaris (x86) and one for Linux in the same project without the
'other' configuration would get overridden every time you opened the project on one of the two platforms.

I fixed this by using the mechanism we had in prior versions (before remote) but integrated it with the remote feature
so now both features work. There is no change for remote configurations. They are managed and work exactly as before.
Local configurations are also managed and work exactly as before except for yow now can control the build platform. A
local configuration can be set to a certain platform and the makefiles are then generated for that platform. This
setting is persistent.

Some details:

I exposed the internal build platform in a property (like it was in previous versions) called Target Platform. This
property controls which platform the makefiles are generated for. This is not new. It's new that it is exposed and can
be set by the user. If Development Host is a remote host, the property is R/O and the value is the platform of the
remote host (just like today). If Development Host is 'localhost', the property can be set to any of the supported
platforms as the target platform for the build. This way you can have one project with multiple configurations for 
building on multiple platforms. This solution is backward compatible with older projects because we already stored the
build platform in the project's metadata. See attached screenshots of the properties in the two different situations.

There is one limitation though: a configuration needs to be managed on the platform it is meant for. It means if you
have a Solaris and a Linux configuration, you need to be on a Solaris box when you want to change the Solaris
configuration and on a Linux box when you want to manage the Linux configuration. They will not override each other
though. The reason you cannot manage a configuration for a different platform is a technical issue with getting access
to for instance Solaris compilers and tools when being on a Linux box. This works nicely with remote but not when you
are local. Still looking for a solution for this.

If possible, please download a fresh build and try it out and let us know if it works for you. You can get a fresh build
here:

http://bits.netbeans.org/download/trunk/nightly/latest/
Comment 4 Thomas Preisler 2009-10-28 05:24:19 UTC
Created attachment 90163 [details]
remote
Comment 5 Thomas Preisler 2009-10-28 05:26:21 UTC
Created attachment 90165 [details]
local host
Comment 6 shiretu 2009-10-28 09:36:44 UTC
Hello,

Tx for the efforts. I'll try it right away. Here are some details about my env and why do I need this. I'm developing a pretty large project (rtmpd.com) and I 
do it in NetBeans. right now I have the following directory structure:

trunk
    sources (...)
    builders
        cmake(...)
        VS2008(...)
        Netbeans
            osx(...)
            FreeBSD(...)
            Linux(...)

I have 14 sub-projects inside so is obvious that maintaining such a thing with separate netbeans projects for each platform will easily get out of control. 
cmake is for deployment and command-line build. Very versatile and truly platform independent. VS2008 is obvious...

I'll try to see if I can "collapse" the content inside the NetBeans folder

Comment 7 Quality Engineering 2009-10-29 00:46:04 UTC
Integrated into 'main-golden', will be available in build *200910281401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/6bde9b5c8fc3
User: Thomas Preisler <thp@netbeans.org>
Log: #168475 Multi-platform support is unusable
Comment 8 Thomas Preisler 2009-10-29 06:13:52 UTC
I removed the Build Property again from the property sheet and we are back to how it was before. The only impact this (removing the property) has, is the 
user needs to be on a certain platform in order to create a configuration for this platform. It may not be that bad because you need to be on that platform 
anyway in order to modify or use the configuration.

So:

* for remote configurations, the platform of the remote host specifies the platform the configuration is generated for. No change here. It is how it has been 
since remote was introduced
* for local hosts, the platform it is created for is remembered and used in two ways:
 1) if you try to build/run the configuration on a different local host, you will get an error message explaining the situation. Again, no change here. It is 
how it has been since last release.
 2) when you save a project, a configuration is now saved for the platform it was created for and not for the platform you happened to be on, which was 
the case prior to my fix.

Now you can have one project with multiple configurations supporting multiple platforms without the local configurations getting rewritten to the platform 
you happen to be on every time you save the project.

There is one catch though: I'm still looking into how to do 2) correctly so you can save for instance a Linux configuration on a Solaris host without having 
access to real toolchains for Solaris. Alexander S. gave me some very promising pointers today and I expect to fix this in a couple of days. But the main bug 
is fixed. 
Comment 9 shiretu 2009-10-29 08:58:24 UTC
That is so cool!

Maybe I'm stretching my luck here... Is there a way to copy one set of configurations (my 14 projects made for OSX) and "convert" them to Linux for example?

Even doing it manually (opening project files inside an editor) is better than setting up all those include folders, link dependencies, etc inside NetBeans from 
scratch using mouse :)

Anyway, I'll try it with a bash script and a lot of search and replace. I'll keep you updated with my results.

Tx again for your efforts
Comment 10 Quality Engineering 2009-10-29 12:09:29 UTC
Integrated into 'main-golden', will be available in build *200910290252* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/dec66be936fc
User: Thomas Preisler <thp@netbeans.org>
Log: #168475 Multi-platform support is unusable
Comment 11 Quality Engineering 2009-10-29 23:14:01 UTC
Integrated into 'main-golden', will be available in build *200910291407* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/6a4ea782750b
User: Thomas Preisler <thp@netbeans.org>
Log: #168475 Multi-platform support is unusable
Comment 12 Thomas Preisler 2009-11-09 08:10:16 UTC
Will drop it to a P3 but still working on it. Remaining issue to resolve: being able to generate makefiles for a different platform that the current platform.
Comment 13 soldatov 2009-11-13 04:08:29 UTC
I have project under Mercurial and it is created in OpenSolaris, when I open it on Linux and add new file, then I need to change platform settings for all configurations (Debug, Release and other). Because "The following configurations were not saved ..." warning is appears.
Comment 14 Thomas Preisler 2009-11-30 19:12:09 UTC
*** Bug 177884 has been marked as a duplicate of this bug. ***
Comment 15 Thomas Preisler 2009-12-16 10:50:10 UTC
*** Bug 178531 has been marked as a duplicate of this bug. ***
Comment 16 Thomas Preisler 2009-12-16 10:52:49 UTC
The core problem is a toolchain is not known/discovered on a platform it is not designed for. For instance there is no SunStudio toolchain available when being on a Mac (I'm not talking about remote). I think what we need is access to all toolchains even in 'local' mode. It will enable you to for instance work on a Solaris/SunStudio configuration being on any platform. Unfortunately it is non-trivial to do. It is certainly not suitable for a patch. Toolchains are very dynamic in their current implementation and basically require the platform they are designed for to be discovered and installed.

I will work on a simpler solution for the patch and a more general solution for 6.9.

A bit of history: before 'remote' came into the picture, things worked just fine. Toolchains were static defined and always available and you could control the platform a specific configuration was meant for. There were two properties in a project. One for platform and one for toolchain. Nothing fancy or automatic.

When 'remote' came along, it kind of hijacked the 'platform' concept and invented a multi-mode called 'local'. 'local' is ambiguous in the sense it means the platform you are currently on and can be anything so what platform is the configuration now meant for? Right, it cannot really be controlled the way users want. Sometime they want to keep a specific configuration as for instance Solaris even you are on a Mac. And generate makefiles for Solaris also when you are on the Mac. I kind of solved the problem with the platform (now it doesn't change it unless the user wants to) but still don't have access to the 'other' platforms toolchains in order to generate the correct makefiles. Using default toolchains works for many projects but not all and you don't know which ones, so this is not a good solution.
Comment 17 Thomas Preisler 2009-12-16 11:28:53 UTC
Changeset 1:
changeset 69fde7ba0320 in cnd-main
details: http://hg.netbeans.org/cnd-main?cmd=changeset;node=69fde7ba0320
Comment 18 Quality Engineering 2009-12-16 12:15:07 UTC
Integrated into 'main-golden', will be available in build *200912161400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/69fde7ba0320
User: Thomas Preisler <thp@netbeans.org>
Log: #168475 Multi-platform support is unusable
Comment 19 Thomas Preisler 2009-12-16 21:30:49 UTC
Changeset 2 (NOI18N):
changeset aceb692b1ade in cnd-main
details: http://hg.netbeans.org/cnd-main?cmd=changeset;node=aceb692b1ade

Changeset 3 (warning dialog):
changeset f8054826d14b in cnd-main
details: http://hg.netbeans.org/cnd-main?cmd=changeset;node=f8054826d14b
Comment 20 dustin_mccartney 2009-12-16 23:28:51 UTC
Thomas...  Most excellent work so far!  (I was examining the changesets.)  :-)

Cheers!
Comment 21 Quality Engineering 2009-12-17 00:13:09 UTC
Integrated into 'main-golden', will be available in build *200912170200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/aceb692b1ade
User: Thomas Preisler <thp@netbeans.org>
Log: #168475 Multi-platform support is unusable
added missing NOI18N
Comment 22 Quality Engineering 2009-12-17 23:51:56 UTC
Integrated into 'main-golden', will be available in build *200912180200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/f8054826d14b
User: Thomas Preisler <thp@netbeans.org>
Log: #168475 Multi-platform support is unusable
Display and manage warning dialog
Comment 23 Thomas Preisler 2009-12-23 10:07:53 UTC
Marking it fixed so the changes can go into 6.8 patch 1.

For patch integrater: fix consists of 3 changesets:

Changeset 1:
changeset 69fde7ba0320 in cnd-main
details: http://hg.netbeans.org/cnd-main?cmd=changeset;node=69fde7ba0320

Changeset 2 (NOI18N):
changeset aceb692b1ade in cnd-main
details: http://hg.netbeans.org/cnd-main?cmd=changeset;node=aceb692b1ade

Changeset 3 (warning dialog):
changeset f8054826d14b in cnd-main
details: http://hg.netbeans.org/cnd-main?cmd=changeset;node=f8054826d14b
Comment 24 soldatov 2010-01-13 06:24:37 UTC
verified in dev trunk build 201001120200
Comment 25 pgebauer 2010-01-14 04:12:55 UTC
The fix has been ported into the release68_fixes repository.
http://hg.netbeans.org/release68_fixes/rev/03d08b357855
Comment 26 Alexander Pepin 2010-01-26 09:31:02 UTC
verified in patch1 candidate build