They are good for in-house development, but not for redistributing,
Yes I would agree with that, My coding is all embedded stuff, I dont re-distribute build environments, except to my own in-house developers, and they all have the same tools, Versions of OS's, etc. I have all sorts of utilities that create source code from data, inject FPGA Bitstreams into my programs, convert the object output formats from GCC into a file suitable for my target, create compressed (custom style) file systems for my target, Build various flavours of my software, etc.
But the results are all installed into hardware we design so we arent interested in redistribution for our needs (at least with this embedded stuff). The point of the post wasnt about Jam per se. I dont expect any IDE to handle Jam specifically. Im not even a Jam zealot I just like it better than Make for my embedded stuff. But I think both suck, Jam just sucks less than Make in my opinion.
What I was really proposing was a "Custom" build option. For example, the configure dialogue would be something like:
Command to Build : [/opt/jam/bin/jam -d2 %t ]
Command to Compile current file: [./build file %f ]
Command to Clean : [/opt/jam/bin/jam clean %t ]
Command to Run : [./DownloadAndExecuteTarget]
Command to Build & Run : [ ] [X] Just Use Build + Run Command
Command to Rebuild : [/opt/jam/bin/jam -d2 -a ]
Command to Clean : [/opt/jam/bin/jam -d2 clean]
Command to Create Distribtion : [./Backup ]
Then all that would happen is that when someone selected Build, the "Command to Build" is executed, and if %t is in the command it is replaced with the name of the target. Or if "Compile current file" is selected, the Command to Compile current file is executed, and %f is replaced with the file name. Im sure you get the idea.
In fact, I could live with what C::B does now, if it didnt add "-f Makefile all" to my Make command. I suppose I could make a script that just tosses those options, but the purpose of the post was to see if it was worth proposing this sort of "optional" build mechanism. Im even happy to implement it at some point in the future (not yet though, gotta get my current project out the door).
I really like the way C::B doesnt force the "automake/autoconf" madness down the throat of the developer. I understand its usefullnes for some projects, it just isnt the panacea that the autotools zealots say it is.
As an aside, how close (as in features and stability for a 1 release, as opposed to timeframe) is C::B to release, because ive only used it for a day, but it seems to be a tad unstable (nothing thats a show stopper, ive managed to work around every problem ive got so far) but im curious.
Stevo
