If you specify
-Dreset=gpio,
propeller-load will use the pin number specified in the environment variable PROPELLER_LOAD_GPIO if it is set or 17 otherwise. You can also specify
-Dreset=gpio<n>
to use a specified pin number.
For example, -Dreset=gpio12 will use gpio 12.
Just a minor point, but a novice looking at an example command line with =gpio, might not know that is looking for an environment variable.
Perhaps a hint in the param ?
-Dreset=env_gpio
or, I also like to have names match for searching purposes, rather than diverged, which give a longer but common
-Dreset=env_propellor_load_gpio
& you set env_propellor_load_gpio to 17
Okay... nvm about cross compiling. Looks like the Makefile isn't quite setup for that.
No, it's not yet. I'm afraid it may inherit that support from the propeller-gcc Makefile. I need to make propeller-load build by itself though.
If you're interested in jumping on the cmake bandwagon, I'd happily convert the build for you.
The problem is, we're stuck with Makefiles for gcc anyway so I don't see any point in using two different build systems. I have enough trouble keeping one straight!
Ah that's right... bleh
Do you still require a patch to cmake or will the standard cmake install work as-is?
That patch I mentioned a long time ago was my own mistake. The implemented a breaking change in v3.4 that I didn't notice. Once I became aware I was able to code up a simple if/else based on the version and execute the proper command for each. It was also specific to PropWare.
Okay, as long as no "sudo" patches are required, I'd be happy to have propeller-load and proploader be converted to cmake. We could also convert lib although Eric currently owns that project. As I said, gcc, binutils, gdb, etc will have to continue to use make.
Okay. So long as you're okay with having GCC then be a mix of GNU Make + CMake, I'm down for converting as much as possible - no root required. Obviously Make can invoke the appropriate CMake commands, but I thought from your previous comment you meant that you wanted the build system to be consistent for PropGCC and all of its children.
I figured we would have to do the reverse: have the cmake script for propeller-gcc invoke make to build gcc, binutils, and gdb.
Okay... nvm about cross compiling. Looks like the Makefile isn't quite setup for that.
No, it's not yet. I'm afraid it may inherit that support from the propeller-gcc Makefile. I need to make propeller-load build by itself though.
If you're interested in jumping on the cmake bandwagon, I'd happily convert the build for you.
The problem is, we're stuck with Makefiles for gcc anyway so I don't see any point in using two different build systems. I have enough trouble keeping one straight!
Ah that's right... bleh
Do you still require a patch to cmake or will the standard cmake install work as-is?
That patch I mentioned a long time ago was my own mistake. The implemented a breaking change in v3.4 that I didn't notice. Once I became aware I was able to code up a simple if/else based on the version and execute the proper command for each. It was also specific to PropWare.
Okay, as long as no "sudo" patches are required, I'd be happy to have propeller-load and proploader be converted to cmake. We could also convert lib although Eric currently owns that project. As I said, gcc, binutils, gdb, etc will have to continue to use make.
Okay. So long as you're okay with having GCC then be a mix of GNU Make + CMake, I'm down for converting as much as possible - no root required. Obviously Make can invoke the appropriate CMake commands, but I thought from your previous comment you meant that you wanted the build system to be consistent for PropGCC and all of its children.
I figured we would have to do the reverse: have the cmake script for propeller-gcc invoke make to build gcc, binutils, and gdb.
Okay, configuration is complete in TeamCity. You'll get new 32-bit Pi and 64-bit Linux builds every time you commit. I can add 32-bit Linux builds tomorrow if you'd like. I'll also start the CMake work tomorrow.
Okay, configuration is complete in TeamCity. You'll get new 32-bit Pi and 64-bit Linux builds every time you commit. I can add 32-bit Linux builds tomorrow if you'd like. I'll also start the CMake work tomorrow.
I don't understand. Haven't you been doing this all along? Or do you mean you're now building propeller-load by itself in addition to building it as part of propeller-gcc?
Okay, configuration is complete in TeamCity. You'll get new 32-bit Pi and 64-bit Linux builds every time you commit. I can add 32-bit Linux builds tomorrow if you'd like. I'll also start the CMake work tomorrow.
I don't understand. Haven't you been doing this all along? Or do you mean you're now building propeller-load by itself in addition to building it as part of propeller-gcc?
Okay, configuration is complete in TeamCity. You'll get new 32-bit Pi and 64-bit Linux builds every time you commit. I can add 32-bit Linux builds tomorrow if you'd like. I'll also start the CMake work tomorrow.
I don't understand. Haven't you been doing this all along? Or do you mean you're now building propeller-load by itself in addition to building it as part of propeller-gcc?
Yea, I mean now it's built by itself too
Thanks for clarifying. Are you planning to also build proploader. It's the new loader that also works over wi-fi connections.
Okay, configuration is complete in TeamCity. You'll get new 32-bit Pi and 64-bit Linux builds every time you commit. I can add 32-bit Linux builds tomorrow if you'd like. I'll also start the CMake work tomorrow.
I don't understand. Haven't you been doing this all along? Or do you mean you're now building propeller-load by itself in addition to building it as part of propeller-gcc?
Yea, I mean now it's built by itself too
Thanks for clarifying. Are you planning to also build proploader. It's the new loader that also works over wi-fi connections.
I'd be happy to. I'll take a look in a bit and report back.
Okay, configuration is complete in TeamCity. You'll get new 32-bit Pi and 64-bit Linux builds every time you commit. I can add 32-bit Linux builds tomorrow if you'd like. I'll also start the CMake work tomorrow.
I don't understand. Haven't you been doing this all along? Or do you mean you're now building propeller-load by itself in addition to building it as part of propeller-gcc?
Yea, I mean now it's built by itself too
Thanks for clarifying. Are you planning to also build proploader. It's the new loader that also works over wi-fi connections.
I'd be happy to. I'll take a look in a bit and report back.
Thanks! No rush as the wi-fi loader code hasn't been officially released yet anyway.
Okay, configuration is complete in TeamCity. You'll get new 32-bit Pi and 64-bit Linux builds every time you commit. I can add 32-bit Linux builds tomorrow if you'd like. I'll also start the CMake work tomorrow.
I don't understand. Haven't you been doing this all along? Or do you mean you're now building propeller-load by itself in addition to building it as part of propeller-gcc?
Yea, I mean now it's built by itself too
Thanks for clarifying. Are you planning to also build proploader. It's the new loader that also works over wi-fi connections.
I'd be happy to. I'll take a look in a bit and report back.
Thanks! No rush as the wi-fi loader code hasn't been officially released yet anyway.
Big thanks goes to the guys at JetBrains who extended my TeamCity license so that I could have more run configs on my server. They provide free licenses to teams developing open source software, and that includes PropWare and all other projects built via http://david.zemon.name:8111.
Big thanks goes to the guys at JetBrains who extended my TeamCity license so that I could have more run configs on my server. They provide free licenses to teams developing open source software,
So you mean to say this is not "Free Software" at all? With a capital "F".
I do hope the source code remains easily buildable with Free tools like a simple make.
Big thanks goes to the guys at JetBrains who extended my TeamCity license so that I could have more run configs on my server. They provide free licenses to teams developing open source software,
So you mean to say this is not "Free Software" at all? With a capital "F".
I do hope the source code remains easily buildable with Free tools like a simple make.
Big thanks goes to the guys at JetBrains who extended my TeamCity license so that I could have more run configs on my server. They provide free licenses to teams developing open source software,
So you mean to say this is not "Free Software" at all? With a capital "F".
I do hope the source code remains easily buildable with Free tools like a simple make.
I'm not sure what "this" refers to when you say "this is not "Free Software"". So I'll explain all the "this"s that I can think of.
TeamCity is closed-source. JetBrains sells TeamCity to users and prices based on the number of "run configurations." A single run configuration usually builds a single artifact, but it could be more. For PropLoader, I use three run configurations: one for Linux x64, one for Windows x86, and another for Raspberry Pis. Each of those run configs produce a single binary: the proploader executable. PropWare has two run configs, one for develop branch and one for the master branch, and each of those produces a lot of executables... I won't list them all. So between PropLoader and PropWare, that is five run configurations. As a free user who did nothing more than download the software from JetBrains's website and start it up, I'm allowed 20 run configurations. When I tried to create the 21st, TeamCity said "nope! you aint paid me yet!"
At that point, I sent email to JetBrains and said "hey guys, you're cool and you like to support OpenSource, so can I get more run configs?" and they replied "heck yes u can! We luv OpenSource!" And boom, now I have unlimited run configs in TeamCity. But only because my TeamCity server only builds OpenSource projects. If I were to add a run configuration for a closed-source project, I would be violating the license that I agreed to upon accepting the unlimited run configs.
Each of the projects built via TeamCity has its own build system - be it GNU Make, CMake, or something else. TeamCity is simply in charge of watching the VCS repository and invoking the build system to produce binaries every time a commit is made. Now, whether or not the project is "easily buildable with Free tools like simple make" is up to the developer. It's certainly possible to include no build system in your project and then have a very long and complicated run configuration in TeamCity that invokes GCC directly... but it won't be me that does the typing in TeamCity's UI to make that happen!
My only concern was that some Free and Open Source software becomes hard to build without some closed source build system.
You assure me that is not the case. I'm cool with that.
I'm not sure what the idea is of introducing cmake to prop-gcc is. I'm not even sure why a loader is included in prop-gcc. GCC is a compiler surely any loader should be in a separate repo/build. like avr-gcc for example.
My only concern was that some Free and Open Source software becomes hard to build without some closed source build system.
You assure me that is not the case. I'm cool with that.
I'm not sure what the idea is of introducing cmake to prop-gcc is. I'm not even sure why a loader is included in prop-gcc. GCC is a compiler surely any loader should be in a separate repo/build. like avr-gcc for example.
Parallax wanted to keep everything together in the beginning of the propgcc project. We split it up a while back into separate repositories but there is still an umbrella repository called propeller-gcc that includes all of the separate pieces as submodules.
I followed some instructions I found for building OpenSpin (and p1load) on a C.H.I.P. (actually a PocketC.H.I.P.). The build went fine except for a warning in eeprom.c on line 211 about a type mismatch in a printf.
Any follow up on this or other suggestions? I won't be able to try it for a week or two (traveling).
I followed some instructions I found for building OpenSpin (and p1load) on a C.H.I.P. (actually a PocketC.H.I.P.). The build went fine except for a warning in eeprom.c on line 211 about a type mismatch in a printf.
Any follow up on this or other suggestions? I won't be able to try it for a week or two (traveling).
I disabled building the eeprom program in the Makefile. It is a new program I was working on that hasn't been fully debugged yet. Sorry for the confusion! The p1load program should have built correctly in spite of the problem with building the eeprom program. Have you tried it?
Comments
Perhaps a hint in the param ?
-Dreset=env_gpio
or, I also like to have names match for searching purposes, rather than diverged, which give a longer but common
-Dreset=env_propellor_load_gpio
& you set env_propellor_load_gpio to 17
Ah, that indeed might be better. CMake has support for "add_externalproject" which is built just for the purpose of having child projects. I use it for Spin2cpp in PropWare: https://cmake.org/cmake/help/v3.0/module/ExternalProject.html
Yea, I mean now it's built by itself too
I'd be happy to. I'll take a look in a bit and report back.
Big thanks goes to the guys at JetBrains who extended my TeamCity license so that I could have more run configs on my server. They provide free licenses to teams developing open source software, and that includes PropWare and all other projects built via http://david.zemon.name:8111.
Anyway, PropLoader binaries for Linux x64, Windows x86, and Raspberry Pi can now be downloaded here:
http://david.zemon.name:8111/project.html?projectId=PropLoader&tab=projectOverview
I should also thank Hen's Teeth Network, Inc., who provides the blazing fast server at a wonderful family discount
I do hope the source code remains easily buildable with Free tools like a simple make.
I'm not sure what "this" refers to when you say "this is not "Free Software"". So I'll explain all the "this"s that I can think of.
TeamCity is closed-source. JetBrains sells TeamCity to users and prices based on the number of "run configurations." A single run configuration usually builds a single artifact, but it could be more. For PropLoader, I use three run configurations: one for Linux x64, one for Windows x86, and another for Raspberry Pis. Each of those run configs produce a single binary: the proploader executable. PropWare has two run configs, one for develop branch and one for the master branch, and each of those produces a lot of executables... I won't list them all. So between PropLoader and PropWare, that is five run configurations. As a free user who did nothing more than download the software from JetBrains's website and start it up, I'm allowed 20 run configurations. When I tried to create the 21st, TeamCity said "nope! you aint paid me yet!"
At that point, I sent email to JetBrains and said "hey guys, you're cool and you like to support OpenSource, so can I get more run configs?" and they replied "heck yes u can! We luv OpenSource!" And boom, now I have unlimited run configs in TeamCity. But only because my TeamCity server only builds OpenSource projects. If I were to add a run configuration for a closed-source project, I would be violating the license that I agreed to upon accepting the unlimited run configs.
Each of the projects built via TeamCity has its own build system - be it GNU Make, CMake, or something else. TeamCity is simply in charge of watching the VCS repository and invoking the build system to produce binaries every time a commit is made. Now, whether or not the project is "easily buildable with Free tools like simple make" is up to the developer. It's certainly possible to include no build system in your project and then have a very long and complicated run configuration in TeamCity that invokes GCC directly... but it won't be me that does the typing in TeamCity's UI to make that happen!
My only concern was that some Free and Open Source software becomes hard to build without some closed source build system.
You assure me that is not the case. I'm cool with that.
I'm not sure what the idea is of introducing cmake to prop-gcc is. I'm not even sure why a loader is included in prop-gcc. GCC is a compiler surely any loader should be in a separate repo/build. like avr-gcc for example.
Any follow up on this or other suggestions? I won't be able to try it for a week or two (traveling).