BitShares Forum
Main => Technical Support => Topic started by: sschechter on March 04, 2014, 03:44:59 pm
-
I write Java code for a living, and quite frankly, I have not seen anything more demoralizing than trying to build the Bitshares/Keyhotee workspace. I have wasted countless hours on this to no avail. Every hurdle cleared is met by the next obstacle. If it were not for the fact that I have a DAC I want to build, I would have given up long ago. I have invested far too much of my time and money for me to let this die. THIS IS A CRITICAL ROADBLOCK FOR ANY POTENTIAL DAC DEVELOPER! For better or worse, my target platform is VS2012/Win7/64. That means in addition to building the workspace on my platform, I need to build every single dependency on my platform too. Quite frankly, the documentation to do this sucks. The error codes suck. The support sucks. Not just I3, but Boost, Qt, etc, everyone who needs to support my platform. It sucks because every platform has its own set of quirks that the user must be familiar with, and if every user is using a different environment, it increases the chances that they get unique errors that no one else has seen before. Why did I pick my platform? Because no one told me "use this" instead. I would much prefer something that I know works than something I have a base level of comfort working in. I was not married to using VS2102, but I may just be now since I've spent so much time on it. If it weren't for sites like Stack Overflow, I would be nowhere. This is not just my problem. This is everyone in the community's problem. If I can't build you a DAC, then you are getting cheated as an AGS/PTS holder. Like I said, I write Java code for a living. I figured there would be some bumps along the way getting re-acquainted with C++, but this is just unacceptable. If I do this for a living and can't get this working, then I can't be the only one whose had issues and given up. I'm willing to bet that there are others who have been made to feel stupid by this opaque process, and that they've been made to think that these issues are due to their own technical limitations.
Here is what I propose as a solution. I3 needs to hire a full time configuration management specialist. They should be responsible for all working build environments. Having a bounty for a working build system is not enough. This CM person would be responsible for maintaining at the minimum, one working Windows, Mac, and Linux environment. They would need to write tutorials for building the workspace for developers. This has to be a step by step guide for building every dependency from a clean machine. Make no assumptions about what the user knows. I want a complete list of tools to use and the URL to find them. It should be written in such a way that a non-developer can set set up the workspace. And finally, they should be supporting developers who are still having issues in order to get it working.
ps - When building Qt statically, I get the following error, so please try to convince me that this doesn't suck:
NMAKE : fatal error U1077: 'cd' : return code '0x2'
-
I write Java code for a living, and quite frankly, I have not seen anything more demoralizing than trying to build the Bitshares/Keyhotee workspace. I have wasted countless hours on this to no avail. Every hurdle cleared is met by the next obstacle. If it were not for the fact that I have a DAC I want to build, I would have given up long ago. I have invested far too much of my time and money for me to let this die. THIS IS A CRITICAL ROADBLOCK FOR ANY POTENTIAL DAC DEVELOPER! For better or worse, my target platform is VS2012/Win7/64. That means in addition to building the workspace on my platform, I need to build every single dependency on my platform too. Quite frankly, the documentation to do this sucks. The error codes suck. The support sucks. Not just I3, but Boost, Qt, etc, everyone who needs to support my platform. It sucks because every platform has its own set of quirks that the user must be familiar with, and if every user is using a different environment, it increases the chances that they get unique errors that no one else has seen before. Why did I pick my platform? Because no one told me "use this" instead. I would much prefer something that I know works than something I have a base level of comfort working in. I was not married to using VS2102, but I may just be now since I've spent so much time on it. If it weren't for sites like Stack Overflow, I would be nowhere. This is not just my problem. This is everyone in the community's problem. If I can't build you a DAC, then you are getting cheated as an AGS/PTS holder. Like I said, I write Java code for a living. I figured there would be some bumps along the way getting re-acquainted with C++, but this is just unacceptable. If I do this for a living and can't get this working, then I can't be the only one whose had issues and given up. I'm willing to bet that there are others who have been made to feel stupid by this opaque process, and that they've been made to think that these issues are due to their own technical limitations.
Here is what I propose as a solution. I3 needs to hire a full time configuration management specialist. They should be responsible for all working build environments. Having a bounty for a working build system is not enough. This CM person would be responsible for maintaining at the minimum, one working Windows, Mac, and Linux environment. They would need to write tutorials for building the workspace for developers. This has to be a step by step guide for building every dependency from a clean machine. Make no assumptions about what the user knows. I want a complete list of tools to use and the URL to find them. It should be written in such a way that a non-developer can set set up the workspace. And finally, they should be supporting developers who are still having issues in order to get it working.
ps - When building Qt statically, I get the following error, so please try to convince me that this doesn't suck:
NMAKE : fatal error U1077: 'cd' : return code '0x2'
There's links here to pre-built versions of static QT for windows (and prebuilt berkeleyDB as well):
https://github.com/InvictusInnovations/keyhotee/wiki/Building-Keyhotee
Downloading and using those is your easiest route, I think. We don't normally build static QT on each of our Windows machines, because it is quite a pain.
-
I write Java code for a living, and quite frankly, I have not seen anything more demoralizing than trying to build the Bitshares/Keyhotee workspace. I have wasted countless hours on this to no avail. Every hurdle cleared is met by the next obstacle. If it were not for the fact that I have a DAC I want to build, I would have given up long ago. I have invested far too much of my time and money for me to let this die. THIS IS A CRITICAL ROADBLOCK FOR ANY POTENTIAL DAC DEVELOPER! For better or worse, my target platform is VS2012/Win7/64. That means in addition to building the workspace on my platform, I need to build every single dependency on my platform too. Quite frankly, the documentation to do this sucks. The error codes suck. The support sucks. Not just I3, but Boost, Qt, etc, everyone who needs to support my platform. It sucks because every platform has its own set of quirks that the user must be familiar with, and if every user is using a different environment, it increases the chances that they get unique errors that no one else has seen before. Why did I pick my platform? Because no one told me "use this" instead. I would much prefer something that I know works than something I have a base level of comfort working in. I was not married to using VS2102, but I may just be now since I've spent so much time on it. If it weren't for sites like Stack Overflow, I would be nowhere. This is not just my problem. This is everyone in the community's problem. If I can't build you a DAC, then you are getting cheated as an AGS/PTS holder. Like I said, I write Java code for a living. I figured there would be some bumps along the way getting re-acquainted with C++, but this is just unacceptable. If I do this for a living and can't get this working, then I can't be the only one whose had issues and given up. I'm willing to bet that there are others who have been made to feel stupid by this opaque process, and that they've been made to think that these issues are due to their own technical limitations.
Here is what I propose as a solution. I3 needs to hire a full time configuration management specialist. They should be responsible for all working build environments. Having a bounty for a working build system is not enough. This CM person would be responsible for maintaining at the minimum, one working Windows, Mac, and Linux environment. They would need to write tutorials for building the workspace for developers. This has to be a step by step guide for building every dependency from a clean machine. Make no assumptions about what the user knows. I want a complete list of tools to use and the URL to find them. It should be written in such a way that a non-developer can set set up the workspace. And finally, they should be supporting developers who are still having issues in order to get it working.
ps - When building Qt statically, I get the following error, so please try to convince me that this doesn't suck:
NMAKE : fatal error U1077: 'cd' : return code '0x2'
+5% +5% +5%
It's been a disaster, I abandoned trying to build as well
They are working on an automated build system but it couldn't come fast enough.
-
I write Java code for a living, and quite frankly, I have not seen anything more demoralizing than trying to build the Bitshares/Keyhotee workspace. I have wasted countless hours on this to no avail. Every hurdle cleared is met by the next obstacle. If it were not for the fact that I have a DAC I want to build, I would have given up long ago. I have invested far too much of my time and money for me to let this die. THIS IS A CRITICAL ROADBLOCK FOR ANY POTENTIAL DAC DEVELOPER! For better or worse, my target platform is VS2012/Win7/64. That means in addition to building the workspace on my platform, I need to build every single dependency on my platform too. Quite frankly, the documentation to do this sucks. The error codes suck. The support sucks. Not just I3, but Boost, Qt, etc, everyone who needs to support my platform. It sucks because every platform has its own set of quirks that the user must be familiar with, and if every user is using a different environment, it increases the chances that they get unique errors that no one else has seen before. Why did I pick my platform? Because no one told me "use this" instead. I would much prefer something that I know works than something I have a base level of comfort working in. I was not married to using VS2102, but I may just be now since I've spent so much time on it. If it weren't for sites like Stack Overflow, I would be nowhere. This is not just my problem. This is everyone in the community's problem. If I can't build you a DAC, then you are getting cheated as an AGS/PTS holder. Like I said, I write Java code for a living. I figured there would be some bumps along the way getting re-acquainted with C++, but this is just unacceptable. If I do this for a living and can't get this working, then I can't be the only one whose had issues and given up. I'm willing to bet that there are others who have been made to feel stupid by this opaque process, and that they've been made to think that these issues are due to their own technical limitations.
Here is what I propose as a solution. I3 needs to hire a full time configuration management specialist. They should be responsible for all working build environments. Having a bounty for a working build system is not enough. This CM person would be responsible for maintaining at the minimum, one working Windows, Mac, and Linux environment. They would need to write tutorials for building the workspace for developers. This has to be a step by step guide for building every dependency from a clean machine. Make no assumptions about what the user knows. I want a complete list of tools to use and the URL to find them. It should be written in such a way that a non-developer can set set up the workspace. And finally, they should be supporting developers who are still having issues in order to get it working.
ps - When building Qt statically, I get the following error, so please try to convince me that this doesn't suck:
NMAKE : fatal error U1077: 'cd' : return code '0x2'
+5% +5% +5%
It's been a disaster, I abandoned trying to build as well
They are working on an automated build system but it couldn't come fast enough.
+5% +5% +5% +5%
-
There's links here to pre-built versions of static QT for windows (and prebuilt berkeleyDB as well):
https://github.com/InvictusInnovations/keyhotee/wiki/Building-Keyhotee
Downloading and using those is your easiest route, I think. We don't normally build static QT on each of our Windows machines, because it is quite a pain.
I did not realize this wiki was there. Thanks for posting this, I will give it a shot tonight.
-Scott
-
Dan N. are these 32-bit versions and should we be using the 32-bit version of everything?
-
I understand your pain, hence as I put the ubuntu compilation guide even if I am a windows developer, as it is far much easier in linux ;). You can quickly setup ubuntu in virtual box if you just want to play with the bits. I also want to build a DAC but I am awaiting to have a simple template to get started, in the meantime I am exploring the code and getting a grasp of what I need to do :). At least now we can generate genesis.json to get started.
-
Dan N. are these 32-bit versions and should we be using the 32-bit version of everything?
Yes, these are 32-bit versions. We're working with 32 bit on windows for greater compatibility across users right now, as there's many 32bit windows users still.
-
I have to admit that even though I am capable of dealing with all the quirks of open source projects, I can not believe that people still think this is a good way to develop.
I'll tell you what - from velocity perspective, the progress could be sooo much better, if we had chosen a different foundation.
Let's hope automated building improves and they build a toolkit that makes it much easier for new DACs to be prototyped and developed. (I know that's the idea)
-
I have to admit that even though I am capable of dealing with all the quirks of open source projects, I can not believe that people still think this is a good way to develop.
I'll tell you what - from velocity perspective, the progress could be sooo much better, if we had chosen a different foundation.
Let's hope automated building improves and they build a toolkit that makes it much easier for new DACs to be prototyped and developed. (I know that's the idea)
What do you mean by "chosen a different foundation"? What recommendations do you have to speed things up?
-
Well it is too late to do that right now. But even though I am an old C++ dog myself. I think it's the wrong language to use for this.
A) Security: it is often the source of buffer overruns and what not - look at the heartbleed bug. For example Rust is a language developed specifically for operating systems and guards against all of these issues.
B) Velocity: languages like Python, go, JavaScript are much quicker to prototype and are platform independent. Ethereum uses those for a reason. And they will go very far very quickly.
I've been toying around with NodeJS and the ease if setup is extremely impressive.
Using any of the listed platforms above would make it a lot less prohibitive for developers to join. Ironically most hardcore crypto people are also stubborn C++ old school folks who think it is safer to avoid using a scripting language.