 |
 |
| View previous topic :: View next topic |
| Author |
Message |
alevyvs
Joined: 06 Jun 2016
Posts: 6
|
| Command line usage of project files |
 Posted: Mon Jun 13, 2016 10:19 am |
 |
|
I'm trying to convert from using a GUI-based project to building via the command line. I don't see either of the following:
- The ability to import/export options from within the GUI. Am I simply missing these? Seems like it would be very helpful for ensuring all team members are building the same way.
- The ability to use an existing project file via the command line. There's documentation if you want to create a new project, but nothing for using one that's previously been built. We use the project file's __BUILDCOUNT__ information as part of our versioning, and I think that's tied to the project file. At least, I'm failing to build due to an undefined identifier on the line that references __BUILDCOUNT__, but please correct me if I'm wrong.
Regarding the second item, I saw here that the BUILD= command can be specified for the old-style .pjt project files, but when I try it with the .ccspjt file my team uses I get an error due to a name conflict. Here's the command line invocation:
| Code: | | CCSC +FD BUILD=main.ccspjt +Y9 +DF +EA -J +T +A +M +LNlst +O8hex +PE -Z main.c |
The error reads:
| Code: | | Duplicate filename on command line. "build.c" and "main.c" |
I don't have any files named build.c, nor do I specify one on the command line. I also tried renaming main.ccspjt to foo.ccspjt to ensure it wasn't an issue to have it named "main.c*" and have that cause a duplicate file name error, but that had no effect.
I also saw here that the order of command line arguments sometimes matters. I've tried playing around with that with no change in the results.
Any advice would be much appreciated!
Edit:
I should have mentioned, we're trying to keep up with the latest version of the compiler, currently version 5.059. |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19552
|
|
| Posted: Mon Jun 13, 2016 11:57 am |
|
|
If you build using a project file, _it_ specifies what file is to be built. It is complaining, since the '.c' file specified in the build, duplicates the file you are loading separately.
Have a look at the project file. It is only a text file. You will see that if you change an option in the IDE, this is recorded in the file. It contains everything needed to build the project. |
|
|
alevyvs
Joined: 06 Jun 2016
Posts: 6
|
|
| Posted: Mon Jun 13, 2016 2:32 pm |
|
|
Oh, thank you! That was foolish of me.
I'm now running into the same issue that I had before learning about the BUILD= option, which is that __BUILDCOUNT__ isn't being recognized.
The error log shows:
| Code: | *** Error 12 "C:\projects\tx550-dsp\version.h" Line 48(24,38): Undefined identifier __buildcount__
*** Error 43 "C:\projects\tx550-dsp\version.h" Line 48(64,65): Expecting a declaration
*** Error 43 "C:\projects\tx550-dsp\version.h" Line 48(64,65): Expecting a declaration
C:\projects\tx550-dsp\main.o ===> 3 Errors, 0 Warnings.
Build Failed. |
The line in question has the following:
| Code: | | #rom int16 0x000208 = {__buildcount__} |
I know that __buildcount__ is defined inside the project file, and global defines are enabled as well. See this snippet from the .ccspjt file
| Code: | [defines]
enabled=1
D1=
V1=
chip=1
buildcount=65 |
Again, this code builds successfully when I try from within the GUI. I'm very puzzled as to why the command line version operates differently. Is there a "hints, tips, and gotchas" document anywhere?
Thanks again. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Jun 13, 2016 3:57 pm |
|
|
The manual says:
| Quote: | __buildcount__
Only defined if Options>Project Options>Global Defines has global defines enabled. |
And then, it also says in the Command Line compiler options section:
| Quote: | #xxx="yyy" Set a global #define for id xxx with a value of yyy, example:
#debug="true"
|
and an alias for the above:
| Quote: |
+Gxxx="yyy"
Same as #xxx="yyy" |
So it's possible that adding the following to the command line might work:
| Quote: | | +G__buildcount__="0" |
|
|
|
alevyvs
Joined: 06 Jun 2016
Posts: 6
|
|
| Posted: Mon Jun 13, 2016 4:13 pm |
|
|
That does work in the sense that it successfully compiles, but it's not quite what I wanted. If I manually insert the build count, that means I have to parse the .ccspjt file for the current value, perform the compilation, and then edit the project file if successful.
As you can see in the snippet I included in my last post, the project file does have global defines enabled. I was hoping that the command line compiler would respect the value. I'll try contacting support to see if this is a bug or not, it certainly seems like odd behavior to me.
Thanks! |
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Tue Jun 14, 2016 4:06 am |
|
|
| alevyvs wrote: | | the project file does have global defines enabled. I was hoping that the command line compiler would respect the value. I'll try contacting support to see if this is a bug or not, it certainly seems like odd behavior to me. |
The compiler doesn't have anything to do with the project file. The IDE manages the project file, sending the appropriate flags in the command line when invoking the compiler. Repeating for clarity: compiler doesn't know about or use the project file. The project file is managed by the IDE.
By invoking the compiler direct by the command line, you are the IDE and you have to manage the things the IDE would normally do. These include the build number.
In case you were wondering, the build number was added, relatively recently, fairly early in the life of version 5, but NOT in all versions, as a result of a direct request by me, and possibly others. Though I cannot say that for sure. I requested it for much the same reason as you appear to be using it: for identification purposes. I am not totally happy with the way it was implemented, but it is a whole lot better than the what was there before, which was nothing. Personally I would not use the command line, essentially considering it a throwback to 1970's ways of working, at least when used manually. I was more than glad to have largely consigned it to history in the 1990s, but I can see command line invoking being useful to allow the compiler to be integrated into a larger, more automated development system. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19552
|
|
| Posted: Tue Jun 14, 2016 6:52 am |
|
|
And of course it is fairly easy to script changing the build number (assuming you are using a script to call the command line).
You can do it really neatly using the serialise ability from a script. |
|
|
alevyvs
Joined: 06 Jun 2016
Posts: 6
|
|
| Posted: Tue Jun 14, 2016 7:16 am |
|
|
| Thanks for the input, everyone. |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
