Bugzilla – Full Text Bug Listing
| Summary: | adding / switching Build Configuration breaks Managed Make | ||
|---|---|---|---|
| Product: | [Tools] PTP | Reporter: | Daniel Harenberg <dharenberg> |
| Component: | Photran.Managed Make | Assignee: | Jeffrey Overbey <com-eclipse-dot-org> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P2 | CC: | com-eclipse-dot-org, dharenberg, michel.devel |
| Version: | 6.0.3 | ||
| Target Milestone: | 6.0.7 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Daniel Harenberg
More information: - If you follow the above procedure and then switch back to the original build configuration (i.e. Debug_IA-32 in the above example), then its makefiles now also contain the equivalent error, i.e. they contain wrong lines with Release_IA-32, even though it does work BEFORE switching configurations. The same problem appears when creating new configurations. - As far as I can tell, all steps for reproducing the error are necessary. In particular, you need to use a module (external subroutines won't produce the error), and the module file needs to be located in a subdirectory (all works fine if main.f90 and mod_hello.f90 are in the same directory). - A workaround is: disable managed make in the project properties -> Fortran Build for all configurations, and remove the wrong statements (eg. Release_IA-32/) manually in all subdir.mk. This is a very burdensome workaround, because it turns changing any compiler options/flags into quite a hassle: the compiler options/flags under project properties -> Fortran Build -> Settings are not available anymore since automatic makefile generation is disabled, so you need to find your compiler flags with a manual, and then you have to edit all subdir.mk, i.e. in the main directory and every subdirectory of the project. *** Bug 339376 has been marked as a duplicate of this bug. *** This is fixed in HEAD (Photran 7) and the ptp_4_0 branch (Photran 6.0.7). The "fix" was to have the dependency calculator avoid looking for modules in derived resources (e.g., the Debug/ folder). It was finding a dependency in Debug/modules/ as well as modules/ and defaulting to the former. Given that we don't know who originally authored the MBS dependency calculator, it has been a recurring source of bugs, and it makes some very restrictive assumptions, we may want to have someone rewrite it in the future... (In reply to comment #3) > This is fixed in HEAD (Photran 7) and the ptp_4_0 branch (Photran 6.0.7). Does that mean that I can look for it in the next minor update (from 6.0.6 to 6.0.7)? That would be awesome! (In reply to comment #3) > Given that we don't know who originally authored the MBS dependency calculator, > it has been a recurring source of bugs, and it makes some very restrictive > assumptions, we may want to have someone rewrite it in the future... My personal view is that the MBS is one of Photran's distinguishing features. There are several other open-source IDEs out there which for the professional programmer are probably as good as Photran. But Photran has some unique features for beginners/ medium experienced programmers, one of which is that it alleviates the need to learn make (or something more modern like scons), another is that it is so much more convenient to simply check compiler flags (and having a few words' explanation with each) instead of memorizing them all. And of course having build configurations. In this respect, it seems Photran is the only serious open-source challenger to MS Visual Studio, which is the standard choice with the Intel Fortran Compiler. If you look at Intel's Linux Fortran Forum, you'll see frequent questions about IDE alternatives, with nothing usable coming up. To come to the point: given the crucial role of a MBS for Photran, it might be a good idea to rewrite it -or parts of it-, maybe using something more modern than make. Not being a programmer myself, that's probably easier said than done, but I would be willing to test any new developments. (In reply to comment #5) > To come to the point: given the crucial role of a MBS for Photran, it might be > a good idea to rewrite it -or parts of it-, maybe using something more modern > than make. I agree, this is something crucial for our students who our not computer scientist (but engineers, physicists, chemists, biophysicists,...) and just want to avoid learning still another thing (inluding make AND gdb...) However, it is important that (unlike Visual Studio) it produces a Makefile that can be used on a national cluster on which it is not always easy to use a GUI, so that "vi" still rules, since on that kind of cluster Python is not always installed or not with the good version for the scons you bring. I have just updated to Photran 6.0.7, where -to my understanding- this bug should have been fixed. To my great disappointment, the exact same problem persists... It seems there was a minimal improvement: in contrast to the first point in Comment 1, now you can switch back to the old configuration, e.g. Debug_IA-32, without it being broken as well. However, adding new configurations still doesn't work. Sorry to repeat myself, but I believe more than ever that this is an important feature of Photran that should be fixed. In addition to the reasons already brought forward, I now started to use compiler flags a lot, which is another -I'd guess frequent- case where build configurations are very helpful. This works for me. Are you sure you have 6.0.7? It was not pushed to the Helios update site, so you have to explicitly install it from the update site http://download.eclipse.org/tools/ptp/updates/helios "Check for Updates" won't pick it up automatically unless you have specifically enabled this site. (This wasn't very apparent in Beth's post, so I'll send out a clarification...) In Help > About > Installation Details, the version of Photran should be 6.0.7.201104291906 Yes, I have that version. I narrowed the problem down: Indeed, if I follow the steps provided in the description, all works fine now! However, the same problem in subdir.mk appears after I do an additional step: 9. In the Fortran projects view, copy and paste the project (giving it a new name) 10. Rightclick on new project -> clean project Now the same error as in the description appears, for the same reason. If instead of cleaning the project you switch configuration and build, again the same error appears. Should I open a new bug and mark this one here as resolved? Yes, please open a new bug for that. Thanks. |