Edit: Duh. Of course, PropGCC doesn't come with make. It is part of the Xcode tools that I use on the Mac and an optional install on most Linux systems. I guess we do include it in the Windows install of PropGCC though.
Recent versions of PropGCC on Windows do not include Make. They used to... I remember taking advantage of it. But then one day, it disappeared .
Even if Make itself were distributed with PropGCC, one still needs to set the correct environment variables to point to PropGCC (PROPGCC_PREFIX) and add Make to PATH - as well as edit their own Project's Makefile to include common.mk included with PropGCC. All of those steps I think need to be "supported" by Parallax (aka, a quick tutorial page hosted under parallax.com).
All build instructions for prop-gcc should be in the README/INSTALL files in the github repo.
Was that supposed to mean "i think the instructions already exist in the README/INSTALL files" or "the README/INSTALL files would be a good place to put them, not parallax.com?"
I was talking about instructions for building prop-gcc itself. Don't know why now.
Certainly all the quirks of actually using prop-gcc and make files and propeller specific options to build propeller code should be documented some place.
Documents and tutorials on parallax.com are ideal for that. But again, such info should be in the upstream prop-gcc repo as the "source of truth".
Edit: Duh. Of course, PropGCC doesn't come with make. It is part of the Xcode tools that I use on the Mac and an optional install on most Linux systems. I guess we do include it in the Windows install of PropGCC though.
Recent versions of PropGCC on Windows do not include Make. They used to... I remember taking advantage of it. But then one day, it disappeared .
Even if Make itself were distributed with PropGCC, one still needs to set the correct environment variables to point to PropGCC (PROPGCC_PREFIX) and add Make to PATH - as well as edit their own Project's Makefile to include common.mk included with PropGCC. All of those steps I think need to be "supported" by Parallax (aka, a quick tutorial page hosted under parallax.com).
I was not involved with creating the SimpleIDE packages. I guess Parallax decided that there was no need for command line tools with an IDE. What is really needed is a way to just install the command line tools including make for those who don't want to use SimpleIDE. As far as I know, there is no Parallax-supported way of doing this.
I was not involved with creating the SimpleIDE packages. I guess Parallax decided that there was no need for command line tools with an IDE. What is really needed is a way to just install the command line tools including make for those who don't want to use SimpleIDE. As far as I know, there is no Parallax-supported way of doing this.
I've run across this problem when using propgcc/make in that I would like to make my code as compatible with SimpleIDE as possible so it's easier to share code with others. For example, I try to use the Simple Libraries unless I have a compelling reason not to. Accordingly, I made a SimpleLibs.mk that I call from my common.mk that includes the library paths, etc. However, it's clear from the mess that it had to be that the Simple Libraries were not designed for that. I think two things could make that a lot easier:
1. SimpleIDE itself could be a make-based IDE, i.e., each time it compiles, it generates a make file based on the current settings, which calls user make files at strategic points. If you don't have the checkbox "Show terminal when compiling" checked, and/or you don't need to put your own make command extensions in, you will be blissfully unaware of this. I think this would make it easier for both Parallax and us users to extend the capabilities of SimpleIDE.
2. Parallax could generate a SimpleLibs.mk file that they keep current, and we could call from our own make file if we need those functions. If SimpleIDE were make-based, it would of course call it itself.
I thought that SimpleIDE was probably make-based, and it was just hidden from us; however if the Windows distribution doesn't even include make, I guess that it must not be. It seems like a large duplication of effort to me, and it makes Jazzed's contribution even that much more amazing.
I would love for SimpleIDE to move in this direction, and I would be willing to support the effort if I could; gosh, I might even use it myself... no, probably not. I'm just old (or something) enough to be set in some of my ways.
Okay, is this a fair summary of yesterday's recommendations? Sorry if I missed something; please feel free to copy/paste and add to the list. Alternately, I can edit this one.
- Host a repository that has the libraries (Propeller GCC, Simple, and Community) all in one place.
- Check repositories and make sure each has documentation on how to build.
- Document how to build and run a Propeller GCC project sans SimleIDE.
How come the Arduino guys never have to know anything about make files or other build complexity?
That is what SimpleIDE should do.
Arduino does not cover as broad of a scope as Parallax wants to/should cover. SimpleIDE already fits the bill for competing with Arduino IDE. But for anyone in the Arduino world, when they get bored, they can switch to Atmel Studio for a more robust and professional development experience. Parallax has no such offering at the moment, and exposing the command line utilities with a bit of documentation is great start.
Okay, is this a fair summary of yesterday's recommendations? Sorry if I missed something; please feel free to copy/paste and add to the list. Alternately, I can edit this one.
- Host a repository that has the libraries (Propeller GCC, Simple, and Community) all in one place.
- Check repositories and make sure each has documentation on how to build.
- Document how to build and run a Propeller GCC project sans SimleIDE.
Almost perfect. I would drop "Propeller GCC" from the list of libraries that should be hosted in the repo. libc doesn't need to be duplicated
Okay, is this a fair summary of yesterday's recommendations? Sorry if I missed something; please feel free to copy/paste and add to the list. Alternately, I can edit this one.
- Host a repository that has the libraries (Propeller GCC, Simple, and Community) all in one place.
- Check repositories and make sure each has documentation on how to build.
- Document how to build and run a Propeller GCC project sans SimleIDE.
I would actually like to be able to include the "simple libraries" in the PropGCC command line distribution. Unfortunately, they aren't really libraries. Last I knew, they are not built into .a files but instead included as source in any project that uses them. Is there any reason they couldn't be distributed as already compiled libraries?
The Simple Libraries are precompiled into .a files in memory model subfolders below the source. It's all in ...Documents/SimpleIDE/Learn/Simple Libraries. They were kept separate from Propeller GCC to allow updates without versioning Propeller GCC.
Recent versions of PropGCC on Windows do not include Make. They used to... I remember taking advantage of it. ...
I was not involved with creating the SimpleIDE packages. I guess Parallax decided that there was no need for command line tools with an IDE. What is really needed is a way to just install the command line tools including make for those who don't want to use SimpleIDE. As far as I know, there is no Parallax-supported way of doing this.
They must still have command-lines generated, as GCC is still a command line tool.
Using make for builds is optional, and many IDEs do avoid that, but what is useful is to expose the command lines they used to create the final binary. - eg in a build.bat file, or MainSource.BAT or similar
That way, you get the same result from the IDE and from external tools.
The better IDEs also allow easy download of an externally updated binary, not sure if SimpleIDE does that ?
Those simple features are invisible to a beginner, but allow all levels of user, and keeps the download common & proven.
The Simple Libraries are precompiled into .a files in memory model subfolders below the source. It's all in ...Documents/SimpleIDE/Learn/Simple Libraries. They were kept separate from Propeller GCC to allow updates without versioning Propeller GCC.
Andy
Thanks for clarifying. I agree that the sources shouldn't be in the PropGCC repository. Maybe the solution is to have a separate install of just the Simple Libraries for use by people who want to use the command line tools or some other IDE. That could be in addition to the all-in-one install that includes SimpleIDE, Simple Libraries, and PropGCC.
The Simple Libraries are precompiled into .a files in memory model subfolders below the source. It's all in ...Documents/SimpleIDE/Learn/Simple Libraries. They were kept separate from Propeller GCC to allow updates without versioning Propeller GCC.
Andy
Thanks for clarifying. I agree that the sources shouldn't be in the PropGCC repository. Maybe the solution is to have a separate install of just the Simple Libraries for use by people who want to use the command line tools or some other IDE. That could be in addition to the all-in-one install that includes SimpleIDE, Simple Libraries, and PropGCC.
As I'm sure you've noticed, to make the Simple library (specifically, the Learn folder) usable, it needs to be reorganized. The least bad solution I came up with in PropWare was to flatten the entire directory prior building the install executable and packaging the flattened version, not the original heirarchy. I use a Python script to accomplish this, and it's the very first step on my build server.
How jazzed handles it in SimpleIDE is beyond me... a herculean effort I think, as was previously mentioned.
Btw Andy, though a build system recommendation isn't required by Parallax, I think it would be much appreciated if one was provided. Case-in-point is drivers. For a simple program that just contains main.c, "propeller-elf-gcc -mlmm -Os -o main.elf main.c" will do just fine. But if you have a .cogc file, life gets more difficult quickly, and there have been a lot of questions regarding how to make it happen. If Parallax provided a build system that could handle these "complex" requests, I think (hope) the community would be very appreciative.
From what I've seen, there are three existing solutions: common.mk in PropGCC (GNU Make), PropWare (CMake), and OmniaCreator (CMake). I don't know what features or bugs exist in each, so I don't mean to be bias toward any one.
When Parallax makes a recommendation for a specific build system, I think they should follow-through by ensuring that each endorsed library is easy to use with said build system. At that point, it will become obvious that Simple could use a refactor.
Okay, so that brings us back to organizing the Simple Libraries with others in some central repository that can be pulled from, either entirely or selectively for various tool creation purposes. In that scenario, maybe we'd be writing a Python script to unflatten it all into the arrangement we see in SimpleIDE.
Here are some [complicating factors]:
Parallax has to make sure that SimpleIDE and its libraries (and many other things) change as little as possible as a service to our educational customers. Reason being, teachers put a lot of effort into building their course materials around it. So, if/when we change something, it can end up taking many by surprise, and causing them a lot of extra work. So, we hold all small changes and ideas for improvement until something uber important comes up, like when ROHS finally ruled on the cadmium sulfide in photoresistors. We had managed not to make any changes for 4 or so years, but when that happened, we incorporated all the revisions we had been collecting at once, and at the same time switched to phototransistors for light sensing. Looking at the copyright of the WAM 3.0 on my desk, the last revision was in 2009. That's not "dead", and in fact, we have to do a lot of work with suppliers to make sure that no changes to kit parts end up necessitating changes to the text.
We had never considered SimpleIDE as a viable option for developers. It started as a testing aid, and was then re-purposed for educational uses. The Simple Libraries started as a test, libraries with functions that emphasized API simplicity over efficiency, code size, etc. I think it would be really cool to have them in a central repository where folks from the community could reduce program size, increase execution speed, and many other good things. ...but, for the most part, there would have to be very few changes to the existing function names and parameters.
[/complicating factors]
Meanwhile, lots of other great things have been created by and for developers. The examples you cited are major: Propeller GCC, PropWare, Omnia Creator, and let's not forget SRLM's libpropeller (sorry to anybody I left out, please chime in). I think it would be really great to have a set of tools that make all these things available. Thinking out loud, bringing all this together needs:
(1) A repository plan that's doable, (2) consensus on the toolchain, (3) participation from all of you
...to make it a reality.
Help making SimpleIDE even simpler is another great project, but I think it would be best to keep that separate from the tool that will evolve to eventually support the Propeller 2. Then, maybe we can put the horse before the cart, and use that developer tool, which will have matured, as a starting point for a future phase in education.
Not necessarily. I specified the command "cc". Could be whatever you like. It would use prop-gcc to get the C files built and whatever it takes to build nice simple PASM like sources into .o files.
Not necessarily. I specified the command "cc". Could be whatever you like. It would use prop-gcc to get the C files built and whatever it takes to build nice simple PASM like sources into .o files.
Unless you allow "cc" to be defined as a script, how do you plan to handle driver code, like cogc files?
That's the big problem that I see. As the Parallax C world sits today, nothing is stopping you from building your programs exactly as you describe, correct? Except for cogc files.
1) Refactor Simple (which implies updating SimpleIDE to work with the new structure)
2) Make a repository for C/C++ libs
3) Define a Parallax-supported toolchain and how to use it
So what would you like to tackle first?
These would be my thoughts on action-items:
Simple
Put Simple on github, in whatever form it currently is. Even if it isn't unusable, just put it on github. Once in public VCS, we can start massaging it as needed.
Toolchain
Start a new thread which collects problem areas (not necessarily bugs, but just difficulties) with PropGCC in the first post and is focused on finding solutions. Once those difficulties are removed, the need for a build system disappears. I'll continue using CMake with PropWare because I like it, and David Betz will likely continue using Make, but heater will finally be able to use a single invocation to gcc to compile his project.
And I think at the same time, Parallax need to investigate both CMake and Make. Both have their advantages and disadvantages. Obviously my draw toward CMake is known, and many others here have spoken up in favor of plain GNU Make. I think there have already been plenty of holy wars on that topic here on the forums, so I don't see the benefit in starting another. Once Parallax has a favorite, they can lay down the requirements for their official tool. With requirements set, we can decide whether to use one of the three existing build systems, or whether to start from scratch.
Common Repo
I'm not entirely sure I agree with the decision to do this, but here's how I would tackle it if I had to:
Simple and libpropeller are easy, because they are nothing more than libraries and fit the scope perfectly. PropWare and OmniaCreator will each need the reusable libraries extracted from the core project before those libraries can be integrated into the common repo.
Once every library has its own repo, with nothing but library code in it, a fifth and empty repo can be created. That will be considered the "parent" and will use git submodules to link in the four libraries. Parallax can then provide zips of this fantastic conglomerate and brag about how awesome the community is.
...how do you plan to handle driver code, like cogc files?
I don't.
Compiling C into COG is a silly idea. Use PASM for such driver code, as we do in Spin.
I thought this at one point as well until I saw Eric's implementation of Pong written in COG C and running in a single COG including the video driver. You can fit useful things in a COG using COG C. It isn't a replacement for PASM but it is useful.
...Put Simple on github, in whatever form it currently is. Even if it isn't unusable, just put it on github. Once in public VCS, we can start massaging it as needed...
Here are the Simple Libraries, example programs and workspace folder that gets added to SimpleIDE:
I'd like to see an official Parallax administrated library on Github that unifies the three main libraries. If Parallax were to do that then I would be willing to donate/support libpropeller's objects (including giving up naming). Something like mraa and upm for the Intel Edison would be a good example of a company maintained library that has community contributions. https://github.com/intel-iot-devkit/mraa For me to use the Propeller would require something like that.
It makes sense that a central place for all Propeller C libraries is needed, but exactly how to do that might need some more thought.
[
They must still have command-lines generated, as GCC is still a command line tool.
Using make for builds is optional, and many IDEs do avoid that, but what is useful is to expose the command lines they used to create the final binary. - eg in a build.bat file, or MainSource.BAT or similar
That way, you get the same result from the IDE and from external tools.
Well, SimpleIDE does show you what command-line calls were made during a build... That data is logged in the Build Status view, below the source view and is made available to copy from the oddly-named, "Build Error Rescue" item in the Help menu. For debugging, I've often copied the commands and run them from the Terminal to get exact results.
You should be able to copy the commands as in this example. I've highlighted the compile command (& others) in red which you would copy into a file or directly to the command-line for execution. Not quite as nice as an automatically created .bat but should work on Mac OS X, Linux or Windows.
.... I've often copied the commands and run them from the Terminal to get exact results.
..... Not quite as nice as an automatically created .bat but should work on Mac OS X, Linux or Windows.
Good example, and looks like an automatically created .bat, should be trivial to add
.... I've often copied the commands and run them from the Terminal to get exact results.
..... Not quite as nice as an automatically created .bat but should work on Mac OS X, Linux or Windows.
Good example, and looks like an automatically created .bat, should be trivial to add
Just remember that .bat files are not widely used in the 'ix world. A shell script with its permissions bits set for execution would be the thing for those systems! So, the app would need to create a file accordingly.
Comments
Recent versions of PropGCC on Windows do not include Make. They used to... I remember taking advantage of it. But then one day, it disappeared
Even if Make itself were distributed with PropGCC, one still needs to set the correct environment variables to point to PropGCC (PROPGCC_PREFIX) and add Make to PATH - as well as edit their own Project's Makefile to include common.mk included with PropGCC. All of those steps I think need to be "supported" by Parallax (aka, a quick tutorial page hosted under parallax.com).
Was that supposed to mean "i think the instructions already exist in the README/INSTALL files" or "the README/INSTALL files would be a good place to put them, not parallax.com?"
I was talking about instructions for building prop-gcc itself. Don't know why now.
Certainly all the quirks of actually using prop-gcc and make files and propeller specific options to build propeller code should be documented some place.
Documents and tutorials on parallax.com are ideal for that. But again, such info should be in the upstream prop-gcc repo as the "source of truth".
I've run across this problem when using propgcc/make in that I would like to make my code as compatible with SimpleIDE as possible so it's easier to share code with others. For example, I try to use the Simple Libraries unless I have a compelling reason not to. Accordingly, I made a SimpleLibs.mk that I call from my common.mk that includes the library paths, etc. However, it's clear from the mess that it had to be that the Simple Libraries were not designed for that. I think two things could make that a lot easier:
1. SimpleIDE itself could be a make-based IDE, i.e., each time it compiles, it generates a make file based on the current settings, which calls user make files at strategic points. If you don't have the checkbox "Show terminal when compiling" checked, and/or you don't need to put your own make command extensions in, you will be blissfully unaware of this. I think this would make it easier for both Parallax and us users to extend the capabilities of SimpleIDE.
2. Parallax could generate a SimpleLibs.mk file that they keep current, and we could call from our own make file if we need those functions. If SimpleIDE were make-based, it would of course call it itself.
I thought that SimpleIDE was probably make-based, and it was just hidden from us; however if the Windows distribution doesn't even include make, I guess that it must not be. It seems like a large duplication of effort to me, and it makes Jazzed's contribution even that much more amazing.
I would love for SimpleIDE to move in this direction, and I would be willing to support the effort if I could; gosh, I might even use it myself... no, probably not. I'm just old (or something) enough to be set in some of my ways.
That is what SimpleIDE should do.
Arduino does not cover as broad of a scope as Parallax wants to/should cover. SimpleIDE already fits the bill for competing with Arduino IDE. But for anyone in the Arduino world, when they get bored, they can switch to Atmel Studio for a more robust and professional development experience. Parallax has no such offering at the moment, and exposing the command line utilities with a bit of documentation is great start.
Almost perfect. I would drop "Propeller GCC" from the list of libraries that should be hosted in the repo. libc doesn't need to be duplicated
The Simple Libraries are precompiled into .a files in memory model subfolders below the source. It's all in ...Documents/SimpleIDE/Learn/Simple Libraries. They were kept separate from Propeller GCC to allow updates without versioning Propeller GCC.
Andy
They must still have command-lines generated, as GCC is still a command line tool.
Using make for builds is optional, and many IDEs do avoid that, but what is useful is to expose the command lines they used to create the final binary. - eg in a build.bat file, or MainSource.BAT or similar
That way, you get the same result from the IDE and from external tools.
The better IDEs also allow easy download of an externally updated binary, not sure if SimpleIDE does that ?
Those simple features are invisible to a beginner, but allow all levels of user, and keeps the download common & proven.
As I'm sure you've noticed, to make the Simple library (specifically, the Learn folder) usable, it needs to be reorganized. The least bad solution I came up with in PropWare was to flatten the entire directory prior building the install executable and packaging the flattened version, not the original heirarchy. I use a Python script to accomplish this, and it's the very first step on my build server.
How jazzed handles it in SimpleIDE is beyond me... a herculean effort I think, as was previously mentioned.
From what I've seen, there are three existing solutions: common.mk in PropGCC (GNU Make), PropWare (CMake), and OmniaCreator (CMake). I don't know what features or bugs exist in each, so I don't mean to be bias toward any one.
When Parallax makes a recommendation for a specific build system, I think they should follow-through by ensuring that each endorsed library is easy to use with said build system. At that point, it will become obvious that Simple could use a refactor.
$ cc -o myProg <options> fileA.c fileB.c fileC.s fileD.s ... -llibSomething...
Those .s files would have to use a PASM-like syntax rather than anything GNU though.
Here are some [complicating factors]:
Parallax has to make sure that SimpleIDE and its libraries (and many other things) change as little as possible as a service to our educational customers. Reason being, teachers put a lot of effort into building their course materials around it. So, if/when we change something, it can end up taking many by surprise, and causing them a lot of extra work. So, we hold all small changes and ideas for improvement until something uber important comes up, like when ROHS finally ruled on the cadmium sulfide in photoresistors. We had managed not to make any changes for 4 or so years, but when that happened, we incorporated all the revisions we had been collecting at once, and at the same time switched to phototransistors for light sensing. Looking at the copyright of the WAM 3.0 on my desk, the last revision was in 2009. That's not "dead", and in fact, we have to do a lot of work with suppliers to make sure that no changes to kit parts end up necessitating changes to the text.
We had never considered SimpleIDE as a viable option for developers. It started as a testing aid, and was then re-purposed for educational uses. The Simple Libraries started as a test, libraries with functions that emphasized API simplicity over efficiency, code size, etc. I think it would be really cool to have them in a central repository where folks from the community could reduce program size, increase execution speed, and many other good things. ...but, for the most part, there would have to be very few changes to the existing function names and parameters.
[/complicating factors]
Meanwhile, lots of other great things have been created by and for developers. The examples you cited are major: Propeller GCC, PropWare, Omnia Creator, and let's not forget SRLM's libpropeller (sorry to anybody I left out, please chime in). I think it would be really great to have a set of tools that make all these things available. Thinking out loud, bringing all this together needs:
(1) A repository plan that's doable, (2) consensus on the toolchain, (3) participation from all of you
...to make it a reality.
Help making SimpleIDE even simpler is another great project, but I think it would be best to keep that separate from the tool that will evolve to eventually support the Propeller 2. Then, maybe we can put the horse before the cart, and use that developer tool, which will have matured, as a starting point for a future phase in education.
Sounds great. Requires changes to PropGCC though
I was helping someone with SDCC recently, (8051 target) and it does get close to what you seek.
It seems to be smart enough to try and create a HEX file and will spawn ASM and Link steps as needed..
However, the devil is in the details, and I got differing outputs depending on whether I used one, two, or three lines.
Seems to be 'a work in progress', but the idea is good.
Unless you allow "cc" to be defined as a script, how do you plan to handle driver code, like cogc files?
That's the big problem that I see. As the Parallax C world sits today, nothing is stopping you from building your programs exactly as you describe, correct? Except for cogc files.
1) Refactor Simple (which implies updating SimpleIDE to work with the new structure)
2) Make a repository for C/C++ libs
3) Define a Parallax-supported toolchain and how to use it
So what would you like to tackle first?
These would be my thoughts on action-items:
Simple
Put Simple on github, in whatever form it currently is. Even if it isn't unusable, just put it on github. Once in public VCS, we can start massaging it as needed.
Toolchain
Start a new thread which collects problem areas (not necessarily bugs, but just difficulties) with PropGCC in the first post and is focused on finding solutions. Once those difficulties are removed, the need for a build system disappears. I'll continue using CMake with PropWare because I like it, and David Betz will likely continue using Make, but heater will finally be able to use a single invocation to gcc to compile his project.
And I think at the same time, Parallax need to investigate both CMake and Make. Both have their advantages and disadvantages. Obviously my draw toward CMake is known, and many others here have spoken up in favor of plain GNU Make. I think there have already been plenty of holy wars on that topic here on the forums, so I don't see the benefit in starting another. Once Parallax has a favorite, they can lay down the requirements for their official tool. With requirements set, we can decide whether to use one of the three existing build systems, or whether to start from scratch.
Common Repo
I'm not entirely sure I agree with the decision to do this, but here's how I would tackle it if I had to:
Simple and libpropeller are easy, because they are nothing more than libraries and fit the scope perfectly. PropWare and OmniaCreator will each need the reusable libraries extracted from the core project before those libraries can be integrated into the common repo.
Once every library has its own repo, with nothing but library code in it, a fifth and empty repo can be created. That will be considered the "parent" and will use git submodules to link in the four libraries. Parallax can then provide zips of this fantastic conglomerate and brag about how awesome the community is.
Compiling C into COG is a silly idea. Use PASM for such driver code, as we do in Spin.
My cc may quite likely be a script of some sort. Not one the user would ever expect to have to look at or change.
Ah, that makes a lot more sense lol. I have to disagree with you, but at least I understand where you're coming from now
Here are the Simple Libraries, example programs and workspace folder that gets added to SimpleIDE:
https://github.com/parallaxinc/propsideworkspace
Also, thanks for thinking it through. Agreed on a new thread. About the central repository, maybe I misunderstood SRLM.
It makes sense that a central place for all Propeller C libraries is needed, but exactly how to do that might need some more thought.
Andy
Output from a recent build:
Project Directory: /Users/altergator/PropCCode/summer/
SimpleIDE Version 1.0.2
/Users/altergator/Documents/SimpleIDE/Learn/Simple Libraries/
/Users/altergator/Documents/
propeller-elf-gcc -v GCC 4.6.1 (propellergcc_v1_0_0_2435)
propeller-elf-gcc -I . -L . -I /Users/altergator/Documents/SimpleIDE/Learn/Simple Libraries/Utility/libsimpletools -L /Users/altergator/Documents/SimpleIDE/Learn/Simple Libraries/Utility/libsimpletools/cmm/ -I /Users/altergator/Documents/SimpleIDE/Learn/Simple Libraries/TextDevices/libsimpletext -L /Users/altergator/Documents/SimpleIDE/Learn/Simple Libraries/TextDevices/libsimpletext/cmm/ -o cmm/summer.elf -Os -mcmm -Wall -m32bit-doubles -fno-exceptions -std=c99 summer.c -lm -lsimpletools lsimpletext -lm -lsimpletools -lm
summer.c: In function 'main':
summer.c:27:7: warning: format '%f' expects argument of type 'double', but argument 2 has type 'float' [-Wformat]
...
propeller-load -s cmm/summer.elf
propeller-elf-objdump -h cmm/summer.elf
Done. Build Succeeded!
You should be able to copy the commands as in this example. I've highlighted the compile command (& others) in red which you would copy into a file or directly to the command-line for execution. Not quite as nice as an automatically created .bat but should work on Mac OS X, Linux or Windows.
dgately
Good example, and looks like an automatically created .bat, should be trivial to add
dgately