Community
Participate
Working Groups
Correct me if I am wrong, but it anyways expands them from the environment which is used during the build. Thus there is no particular reason to put the expanded values into the generated makefile.
Created attachment 185952 [details] patch that deletes the corresponding code
It has been a long time but I seem to recall this was needed to prevent file-speciic rules from malfunctioning in certain cases. I don't think we can just delete this. Is this causing a problem for you in any way?
Yes, it does. I need unexpanded macros in my makefile, since I am going to use it later for the headless builds. Rounded brackets don't expand, but in this case I am not able to build a single file.
AFAIK by HeadlessBuild Anna means she's running 'make' externally on the generated makefiles, and not using the provided HeadlessBuilder IApplication.
James is correct.
(In reply to comment #3) > Yes, it does. I need unexpanded macros in my makefile, since I am going to use > it later for the headless builds. Rounded brackets don't expand, but in this > case I am not able to build a single file. I don't really follow. If the makefile builds within the IDE then it would build at the command line too. Expanding the macros fully should just result in a slightly more verbose makefile that doesn't use any make variables in some of the rules.
It bears pointing out that the macro expansion is done really so that any internal macros whose values are provided by Eclipse are expanded in their proper context. Although expanding environment variable might not usually seem useful given that make will do this on its own, it's possible to nest environment variables inside build system macros. The burden place on the macro suppliers is low, so they generally expect to be given fully expanded arguments.
(In reply to comment #7) >The burden place on the > macro suppliers is low, so they generally expect to be given fully expanded > arguments. Actually, to be more correct... the build system macros themselves don't take arguments. Eclipse Variables are valid to use though as well, and they can take arguments.
Here is an example for you. If I want to create, say, an rpm package from a project, rpm would provide all the variables it needs. But with the expanded macros, it won't build most likely. Or, sometimes I need a project built with arm/mips/ppc/what else have you toolchains. I really don't want to regenerate a makefile to be able to do it, I just want to change the variables.
(In reply to comment #9) > Here is an example for you. If I want to create, say, an rpm package from a > project, rpm would provide all the variables it needs. But with the expanded > macros, it won't build most likely. Or, sometimes I need a project built with > arm/mips/ppc/what else have you toolchains. I really don't want to regenerate a > makefile to be able to do it, I just want to change the variables. But from Chris' point, either it builds from within Eclipse or it doesn't. If you're building outside of Eclipse, using the makefile with _different_ environment to what's specified in the project configuration, then you're not actually building the same configuration that Eclipse is building. The build product would be different to what you get using HeadlessBuilder, or building from within the GUI. When we discussed this as CDT-con I think your use-case was to allow specifying different environment so you could effectively fake up multi-configuration builds without multiple configurations? The problem is that people assume the current behaviour. So I think to get this integrated a few things would need be done: - Make the behaviour optional: perhaps a hidden preference that you can toggle programmatically / in your product? - What do the tests look like with the patch applied?
Test results look the same with the patch as without it.
(In reply to comment #11) > Test results look the same with the patch as without it. Really? That's surprising as a load of the tests compare the generated makefiles... Are you saying they're all failing for you ;)?
I ran the managedbuilder.core.tests, they have 3 failures out of 106 on my machine( openSuse 11.2, Eclipse 3.7M4) without my patch. Also sometimes they hang. I don't have a Windows machine to try it unfortunately.
I don't think there are a lot of tests that exercise the macro functionality (if there are any at all), so I don't think the tests are a good indication. Honestly I don't think we can use this patch as is, as it will break a lot of things. We need a more complex solution for the variable expander to know what variables should be expanded and what variables should be left alone. Variables internal to Eclipse will always have to be expanded; environment variable references are the only ones that could be left as makefile variables. Even then, this behaviour would have to be optional.
