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.
I don't know when this broke (because for unrelated reasons I was not using netbeans to build), but make commands that used && to do multiple dependent steps no longer works. For example, make foo && cp foo .. is a standard way of making 'foo', but copying foo to .. would only be attempted if the make succeeded. This is broken at least in the build below. And yes this is a critical aspect of make, hence the P1. Product Version: NetBeans IDE Dev (Build 201101180000) Java: 1.6.0_18; Java HotSpot(TM) 64-Bit Server VM 16.0-b13 System: Linux version 2.6.35.10-74.fc14.x86_64 running on amd64; UTF-8; en_US (nb) Userdir: /home/toddb/.netbeans/dev
... nor does any form of multiple commands for the make work (commands separated by newlines, semicolons, parenthesis, &&, etc.) Looks like the parser knows nothing about shell syntax and passes the arguments to execvp() instead of to a shell parser like system(). That would be a pretty big change. No one noticed?
Where do you specify this command? In the Build Command in the project properties? Or?
[right click on project]-->Properties Build->Make->BuildCommand I'm pretty sure this worked from 6.5 through 6.9.
Issue confirmed. Solution being discussed....
This could have been caused by the move from using makefiles to build the configurations to using xml entries in configurations.xml. I stumbled across that when I noticed that some files are no longer being generated by netbeans, as described in Bug 194602.
Please see http://netbeans.org/bugzilla/show_bug.cgi?id=192730
Thanks. That is informative, and I can see why you might want to move away from multiple generated makefiles. Since that does not address how to handlle invocation of the build that contains more than a single "make" command, I assume that is still under discussion.
(In reply to comment #7) > Thanks. That is informative, and I can see why you might want to move away from > multiple generated makefiles. > > Since that does not address how to handlle invocation of the build that > contains more than a single "make" command, I assume that is still under > discussion. we've implemented issue #192730 to address this complex use cases as well. The easiest way for users now should be: create script with as many command you'd like and put it's invocation as Build->Make->BuildCommand As soon as you was confused with new behavior we definitely should improve this "change of a concept" I.e. we need to analyze input existing Build->Make->BuildCommand string and propose to create build script if it is too complex (i.e. contains &&,||, <, > and other such symbols) what do you think?
> we've implemented issue #192730 I think I understand the changeset (http://hg.netbeans.org/main/rev/f4a2885935a2). > we need to analyze input existing Build->Make->BuildCommand string and > propose to create build script if it is too complex (i.e. contains > &&,||, <, > and other such symbols) > > what do you think? I think there's a risk of more bugs when the user starts with a build command like make foo and changes it to make foo; The first would be executed directly and the second through a build script. They may run the same... and they may be different, generating bugs difficult to find and fix. I think you have three options: 1. the one you have suggested above. As a user, I will like it, but you may be the one suffering with more bugs. Or maybe not. 2. Always generate and execute a build script. This would always give you consistent results. 3. Drop support for multiple commands in the BuildCommand. This would break compatibility with functionality established in 6.5 through 6.9 (i.e., this bug), but it would simplify support. My choice is #1. Duh. I would think that your best choice is #3, but now your problem is with users like me that depend on the earlier semantics. You could probably make this easier by trying to identify shell control symbols (<, >, ;, &, &&, etc) and produce a dialog that would point out the change in the build command support, and perhaps even a suggested workaround. Suggesting that the user add a new make target that could be invoked from the NB build command might not be something the user would appreciate, especially with pre-existing code/makefiles. If you had a workaround that took me 30 seconds to implement, that would probably not get any complaints. Users always get in the way of meaningful progress :-)
There appear to be other related issues with the new design, but unrelated to the handling of shell control syntax: - I have one project where I have specified the build command as "${MAKE} -f Makefile LINUX_CDEBUG_FLAGS=-g linux64" yet when I hit the build button I see at the top "make PLATFORM=linux64". For this same project it also does not try to build the dependencies. I'll attach the configuration. - In other projects, it seems to do the build the way I specified (same as above), yet I'd like to see the make command that was run in case I need to adjust the build command.
Created attachment 105314 [details] config where "build" does not use configured build command and dependencies not built
Yes, this is another fallout of this change. Building Required projects are handled by the generated makefiles. No makefiles => required projects are not being built. We are still discussing what to do, but thanks for you input so far.
I have decided to back out the changes for 192730 - IDE should not use unneeded artifacts for unmanaged projects until we have a better handle on the consequences. We should be back to where with generated makefiles. I consider this fixed. And thanks for your input. It has been valuable.
We are still discussing possible solutions and have a question: Our feeling is that dropping support for complex shell-like build command like the one you are using is acceptable because there are a reasonable work-arounds, but what if we also drop support for building dependent projects for unmanaged projects? Would that affect your work in a significant way? And again, thanks for you input.
> dropping support for complex shell-like build command like > the one you are using is acceptable Ahh, #3 above. Probably a rational choice. > but what if we also drop support for building dependent projects > for unmanaged projects? Would that affect your work in a significant way? Maybe this is ok... as long as I can see the make command line in the build output window, which I can't now. I may feel better about this when I get the build with the changes for 192730 removed. I have little control over make in NB right now, and I don't trust it... I run the make from the command line. Our makefile architecture lists dependent projects in each makefile and builds them automatically. This is true for every multi-directory project in the wild that relies on makefiles. So as long as I can invoke the 'make' the way I want to, I'm ok. And I think others would be too. [begin minor detour...] I started out with monolithic projects that included all the source code. This generated a number of bugs because NB has a single world view of include files even though some source files may define other directives that would enable different parts of the include files. The result was lots of (invalid) red marks in the IDE editor. More recently, I have defined individual projects, one for each directory, much the same way you would for one makefile in each directory. This allows much better control over code assistance that improves things greatly. [...end detour] So NB drives me toward multiple dependent projects (DP). What else does dependency (in unmanaged projects) in NB cover? - loading/opening DP when I open the main project - setting breakpoints in DP when I run the main project (?) - auto-saving files in DP when I hit run/debug. I hope so. The point here is that "dependent projects" ought to still have a coherent meaning. I would think your risk is that you unhook building DP and something else gets unhooked in the process.