Created attachment 100761 [details]
The annoying dialog

Is it still an issue?

The generated projects are not designed to be platform agnostic, the metadata is but the generated project files are not and has never been. This is an issue that keeps coming back and to solve it is a very hard problem. Think of complex projects with subprojects and libraries and it becomes almost impossible to generate a project that builds correctly on all platforms. Moreover it is rarely an issue for 'real' users because the issue is normally solved with multiple configurations (one of the reasons configurations exists), it is probably only an 'issue' for us developers that have small simple projects we would like to move from system to system and don't want to create multiple configurations for. 

Alexander has mitigated the issue by introducing 'default compiler' but it does not solve the underlying problem. Will change this IZ into an enhancement and use it as an umbrella issue for similar bug reports. I will also dome discussions we have had about this issue.

*** Bug 195980 has been marked as a duplicate of this bug. ***

On 11/30/10 00:15, Thomas Preisler wrote:
>
>
> On 11/26/10 2:12 AM, Alexander Simon - Oracle - St Petersburg Russia wrote:
>> Thomas,
>>
>> I have an idea.
>> Now IDE generates one make file for each configuration, i.e. we have:
>> Makefile-${CND_CONF}.mk
>> that launched by
>> #${MAKE} -f nbproject/Makefile-${CND_CONF}.mk
>> In this case Makefile-${CND_CONF}.mk has platform and tool collection
>> specific properties. And as result we have different Makefile-${CONF}.mk
>> on different platforms and different tool collections (and blinking in
>> VCS).
>> My proposal is:
>> Generate make file:
>> Makefile-${CND_CONF}-${CND_PLATFORM}.mk
>> that launched by
>> #${MAKE} -f nbproject/Makefile-${CND_CONF}-${CND_PLATFORM}.mk
>> In this case Makefile-${CND_CONF}-${CND_PLATFORM}.mk is not changed from
>> one platform/tool collection to other.
>> We have a set of make files for each configurations, platforms and tool
>> collections on which building was done.
> One problem: it doesn't scale very well. Try and count how many makefiles you will need to generate.
Example. We have "Welcome" application and try to share application on Windows+Cygwin, Windows+MinGW, Linux+GNU, Mac+GNU, Solaris-x86+GNU, Solaris-x86+SunStudio, Solaris-sparc+GNU, Solaris-sparc+SunStudio with Debug and Release configurations. We have to have 16 configurations and 16 makefiles. Yes?
In my case we have 2 configuration and 16 makefiles. Where is scalability problem? It exists on both solutions.
>> Once generated specific Makefile-${CND_CONF}-${CND_PLATFORM}.mk does not
>> changed from one user/platform to another.
>> Building from command is line available for all known (generated)
>> combinations configurations/platforms/tool collections.
>> Of course building from IDE regenerates make files for current platform
>> and tool collection (possible for all configurations) and does not touch
>> "foreign" make files.
> Don't understand: if you don't generate all makefiles, you will have makefiles that are out of sync and some don't match the state of the project. Isn't that a problem?
Yes it is a problem. But this problem exist in old approach. Makefile generated for Windows+Cygwin Debug configuration does not compatible with Solaris-sparc+SunStudio Debug configuration. In my solution IDE does not harm Solaris-sparc+SunStudio make file if we are working on Windows+Cygwin. Of course to regenerate Solaris-sparc+SunStudio makefile on Windows we have to use remote host or start IDE on Solaris-sparc.

Alexander
> It is one of the issues I have been trying to solve but unfortunately the way our toolchains are written, you don't have access to enough toolchain information unless you are on the system you want to generate a makefile for. in other words, it is currently not possible to generate a correct makefile for a system you are not on (or have access to via remote).
>>
>> What do you think about?
>>
>> Alexander
>>
>> 11/23/10 12:20, Alexander Simon - Oracle - St Petersburg Russia wrote:
>>> Thomas,
>>>
>>> Thanks for comments. It confirms that:
>>> - configuration should be platform independent.
>>> - make files was designed platform dependent.
>>> - configure step is absent by design.
>>> - project developed on one platform cannot build without IDE on
>>> another platform.
>>>
>>>
>>> 11/22/10 23:19, Thomas Preisler wrote:
>>>> Alexander,
>>>>
>>>> The projects were originally designed to be portable across platforms
>>>> but not the generated makefiles themselves. If you move to another
>>>> platform, you will have to generate new makefiles using a suitable
>>>> tool chain on the new platform. Platform specific compiler flags are
>>>> baked into the generated makefiles and they will only work with the
>>>> compilers used to generate them. Configurations were designed to deal
>>>> with the cross-platform issue. One configuration per platform and you
>>>> are (almost) set. That was a design decision we made a long time ago.
>>>> One note here: CND developers like us and QA tend to have small
>>>> projects that they often move between platforms. We don't like to
>>>> create multiple configurations so we run into the cross-platform
>>>> issue quite often.
>>> Why we do not have "multi platform" sample? How IDE helps user to
>>> understand that multi platform project is much more then welcome
>>> application?
>>>> Is the same also true for our users? Is it a big issue for our users?
>>>>
>>>> What you are trying to do with introducing a concepts like 'default'
>>>> compiler set is trying to make the generated makefiles look like they
>>>> are portable.
>>> It is not true. I try to remove "blinking" properties from
>>> configurations to achieve mentioned rule "Configurations were designed
>>> to deal with the cross-platform issue".
>>> If user does not uses specific flags in configurations the default
>>> tool collection is good enough on all platforms. But user still has
>>> opportunity to create compiler specific configuration for concrete
>>> tool collection.
>>> So removing from public configuration
>>> - user/host
>>> - platform
>>> - tool collection
>>> - absolute path to library configuration
>>> make configuration *real* cross platform.
>>>> But they are not, and you will not really fix anything by doing this.
>>>> Just move or 'hide' the problem. The platform specific flags are
>>>> still in the generated makefiles and the only thing you obtain is
>>>> that the project doesn't build (because the flags are wrong).
>>>>
>>>> I think this change is wrong and actually make the problem worse by
>>>> make the project appear they work on other platform when they are not.
>>>>
>>>> A correct approach to fix the cross-platform problem is, in my
>>>> opinion, something like the following:
>>>>
>>>> Remove all platform specific flags from the generated makefiles and
>>>> pass them in at build time directly from the used tool chain.
>>>>
>>>> Example: instead of generating the following line for dynamic libraries:
>>>>
>>>> ${LINK.cc} -dynamiclib -install_name libCppDynamicLibrary_3.dylib -o
>>>> ${CND_DISTDIR}/${CND_CONF}/${CND_PLATFORM}/libCppDynamicLibrary_3.dylib
>>>> -fPIC ${OBJECTFILES} ${LDLIBSOPTIONS}
>>>>
>>>> we should generate something like this:
>>>>
>>>> ${LINK.cc} ${DYNLIB_OPTIONS}
>>>> libCppDynamicLibrary_3.${DYNLIB_EXTENTION} -o
>>>> ${CND_DISTDIR}/${CND_CONF}/${CND_PLATFORM}/libCppDynamicLibrary_3.${DYNLIB_EXTENTION}
>>>> ${DYNLIB_EXTRAFLAGS} ${OBJECTFILES} ${LDLIBSOPTIONS}
>>>>
>>>> and somehow pass DYNLIB_OPTIONS, DYNLIB_EXTENTION, DYNLIB_EXTRAFLAGS
>>>> to the makefile at the time when you actually build the dynamic
>>>> library. Then the generated makefiles become truly cross-platform.
>>>> You get the idea. Make sense?
>>> Unfortunately it does not work because project can have individual
>>> flags set for each compile unit.
>>>
>>> Alexander
>>>>
>>>> This is however a *major* redesign of the makefiles and would require
>>>> a study and some working (handcrafted?) prototypes? before we can be
>>>> sure it can be done. It would be absolutely great if it could :-)......
>>>>
>>>> --thomas
>>>>
>>>> On 11/18/10 1:23 AM, Alexander Simon - Oracle - St Petersburg Russia
>>>> wrote:
>>>>> 11/18/10 03:10, Thomas Preisler wrote:
>>>>>
>>>>> Thomas,
>>>>>
>>>>> Thanks for comments.
>>>>> We have a lot of issues with project sharing. I try to summarize issues
>>>>> in the wiki:
>>>>> http://dptwiki.sfbay.sun.com/twiki/bin/view/Ide/SharedProject
>>>>> It would be great if you add important scenarios into the user view.
>>>>>
>>>>> So let try to understand what you mean (1):
>>>>> - user share project with private data by NFS.
>>>>> - user open project by IDE on computers with different tool
>>>>> collections.
>>>>> - IDE cannot build project because make file incompatible.
>>>>> Yes?
>>>>> Answer: It is known bug of project system. Project system should be
>>>>> enough wise to regenerate make file without any annoying dialogs. Yes,
>>>>> default tool collection makes bug more visible and add more complicated
>>>>> support for event "default tool collection is changed" in project
>>>>> system
>>>>> (and model).
>>>>>
>>>>> Another scenario (2):
>>>>> - user share project by VC without private data.
>>>>> - user open project by IDE on computers with different tool
>>>>> collections.
>>>>> - IDE cannot build project because make file incompatible.
>>>>> Answer: See previous answer.
>>>>>
>>>>> Scenario (3):
>>>>> - user share project with private data by NFS.
>>>>> - user build project by command line on computers with different tool
>>>>> collections.
>>>>> - make failed because make file incompatible.
>>>>> Answer: Scenario do not work at all. Project system need to introduce
>>>>> "configure" script that regenerates make files.
>>>>>
>>>>> Scenario (4):
>>>>> - user share project by VC without private data.
>>>>> - user build project by command line on computers with different tool
>>>>> collections.
>>>>> - make failed because make file incompatible or absent.
>>>>> Answer: See previous answer.
>>>>>
>>>>> I see that "default" tool collection does not introduce new issue (only
>>>>> escalate existent) .
>>>>>
>>>>> Why I did this changes? NB project (nbproject folder) should be divided
>>>>> on 2 area:
>>>>> - Public area contains common project data that can be shared by VC.
>>>>> - Private area contains user/platform/computer sensitive data (and all
>>>>> generated data if it user/platform/computer specific) that should not
>>>>> shared by VC.
>>>>>
>>>>> Alexander
>>>>>> Alexander,
>>>>>>
>>>>>> I have seen your changes to fix 192036. You have invented a 'default'
>>>>>> toolset and removed the actual name of the toolset from the
>>>>>> configuration file. This will cause problems for managed projects:
>>>>>>
>>>>>> The generated makefiles and the actual compiler set are tightly
>>>>>> connected and need to 'stay' together when you check them in or move
>>>>>> the project between systems. If you check in the makefile, you will
>>>>>> also need to check in the actual name of the toolchain you used to
>>>>>> generate them. Try to create a dynamic library project on a Solaris
>>>>>> system where SolStudio is the default set. Move the project to for
>>>>>> instance another Solaris system where there is only GNU compilers
>>>>>> (simulating check-in/check-out), you will now see the project will get
>>>>>> attempted build but the compiler will choke on the generated flags.
>>>>>> There are other combinations where it will now go wrong. Before it
>>>>>> wouldn't even attempt to build and ask for the right compiler set
>>>>>> before it would continue. Your changes may be correct for unmanaged
>>>>>> projects (that's what the bug was about!) but it definitely wrong for
>>>>>> managed.
>>>>>>
>>>>>> Please consider backing out your changes out for managed projects.
>>>>>>
>>>>>> --thomas
>>>>>
>>>
>>