Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
Exotic Build Environment Support
Stevo:
--- Quote ---They are good for in-house development, but not for redistributing,
--- End quote ---
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
rickg22:
Usually after every release there are a number of uncatched bugs. Look at the sourceforge project page (via the codeblocks homepage), and you'll see about 30 bugs reported for RC2. It's a record! :lol:
Anyway the crashes and most critical bugs are the ones fixed first.
m00:
I second with Stevo's suggest. I want to use Jam too. Look forwarding for after 1.0! ;)
grv575:
In any case I don't see the point in hardcoding
-f Makefile
as that's the default anyway so nothing is gained.
nor
make all
instead of just make
since all should be the first target in the Makefile...
mandrav:
--- Quote from: grv575 on December 28, 2005, 10:00:56 pm ---In any case I don't see the point in hardcoding
-f Makefile
as that's the default anyway so nothing is gained.
nor
make all
instead of just make
since all should be the first target in the Makefile...
--- End quote ---
I don't see the point for this discussion anymore, since the actual make commands are user-configurable per project/target...
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version