Friday, May 26, 2017
CMake, Mobiles and Command lines.
So, this week has been a compilation of all things CMake as my objective for the new month starting Monday is to get a working build for the project. All in all, I can say that I'm much closer to a CMake Toolchain that can target Apple, Linux, Windows, Android, and iOS with minor tweaks. As I said in my last post, Android is a huge beast that is hard to conquer since it needs the Android SDK and C/C++ NDK in order to work with our project. Now, I've decided to use Android Studio as the target IDE for it has Make files built in and already CMake/Gradle already installed. The only project is that Android Studio has the huge hurdle of not being a Generator for CMake. What I've decided to do is generate the files as make files and then, using the internal CMake files and Gradle system that Android Studio has, build the project using those through Studio. Now, the only way to do so newer programmers and novice to the CMake system can be able to get a working project without completely ruining anything or spending 12 hours on it is to create scripts and batch files so that the entire process can be handled in the console/terminal of the current platform. Though, I haven't tested this out yet because I had to put this part of the project on hiatus since the ever-approaching deadline. My attention is focused elsewhere, an actual working toolchain that can be used on a static folder that will build on any three of the main target platforms which are the Windows, Mac, and Linux. In this retrospect, I've made tremendous progress. I've officially created a batch file that can take a source folder and build a visual 15 project without needing a target. All a person needs to do is simply run the batch and it will run CMake without any more input. I've created a script for Mac which is currently not working due to CMake being unable to find the C compiler even though I am telling it the location of the compiler. My work on the Linux machine has been lost since my Virtual Machine crashed on me and the snapshot of my work is corrupted. I need to rebuild the system all over again. Summarizing all of this, this past week has been both nerve-wracking and enlightening. I come ever so closer to accomplishing my task but yet feel so far away from it. Next week we start working on actually putting work into the live project server. I will post about this again next week on my progress.
Monday, May 22, 2017
Integrating GWindow Tests
Month Two : Week Three
This week was a week of frustrations mostly because I was working on something that was slowing me down and keeping me from starting windows development. After the completion of my unit tests last week I was tasked with getting those tests running in the CodeBlocks and XCode environments. This is when I realized that my task for week one of integrating the unit tests into the main repo was not only for Windows, but for the other two platforms as well. I had intended to integrate the unit tests for Mac and Linux while I developed the implementation for them, therefore only the Visual Studios solution was integrated at this time. However, the issue was that to get my GWindowTests testing, I now needed the unit tests for XCode and CodeBlocks to be integrated as well. Because I h ad not allocated time for these tasks, I knew they were going to get me behind.
The issue within the aforementioned issue is that I was still somewhat unfamiliar with the CodeBlocks and XCode IDE's and trying to import a project from one workspace to another without Linker errors requires in depth knowledge of the IDE's project settings. This meant that integration would not be a quick process and would require a fair amount of research and testing. Even integrating the unit tests in my most familiar IDE, Visual Studios, took more time than I had initially allotted for it. This worried me because initially I thought I was ahead of schedule and ready to start windows development, when really I was essentially still working on my first task for the month.
For this problem, the only solution was time. I started with Linux and spent a lot of time inside the CodeBlocks IDE exploring and researching how the project was set up for the initial stand-alone test suite. After getting myself acquainted with the project settings, I looked for a way to port the project straight into the existing Gateware workspace. Unfortunately, for whatever reason, CodeBlocks has no built-in way to import one project into another which meant that I had to create a new blank project and then add and edit the files individually. This was very time consuming because of the sheer amount of options that had to be set. Many times I was sure I was done only to find another change somewhere I had overlooked in the stand-alone that I had not mimicked in the new project.
This process repeated itself almost exactly when I began integrating the XCode projects. I was even less familiar with this IDE but I got lucky and it ended up not taking any longer than the CodeBlocks integration. Really the solution besides spending lots of extra time in the IDE was going back and forth from stand-alone tests project settings to the newly created test project settings and making sure they matched up in every case. This was difficult in XCode and CodeBlocks because these IDE's do not support having multiple instances of themselves up like Visual Studios does. At the end of the day, I got both projects integrated and by the end of the week I was only about three days behind where I expected to be, which isn't a terribly unmanageable gap. Even though I was unclear of my expectations for week one, I was able to overcome the extra work by staying on task and working a little extra.
This week was a week of frustrations mostly because I was working on something that was slowing me down and keeping me from starting windows development. After the completion of my unit tests last week I was tasked with getting those tests running in the CodeBlocks and XCode environments. This is when I realized that my task for week one of integrating the unit tests into the main repo was not only for Windows, but for the other two platforms as well. I had intended to integrate the unit tests for Mac and Linux while I developed the implementation for them, therefore only the Visual Studios solution was integrated at this time. However, the issue was that to get my GWindowTests testing, I now needed the unit tests for XCode and CodeBlocks to be integrated as well. Because I h ad not allocated time for these tasks, I knew they were going to get me behind.
The issue within the aforementioned issue is that I was still somewhat unfamiliar with the CodeBlocks and XCode IDE's and trying to import a project from one workspace to another without Linker errors requires in depth knowledge of the IDE's project settings. This meant that integration would not be a quick process and would require a fair amount of research and testing. Even integrating the unit tests in my most familiar IDE, Visual Studios, took more time than I had initially allotted for it. This worried me because initially I thought I was ahead of schedule and ready to start windows development, when really I was essentially still working on my first task for the month.
For this problem, the only solution was time. I started with Linux and spent a lot of time inside the CodeBlocks IDE exploring and researching how the project was set up for the initial stand-alone test suite. After getting myself acquainted with the project settings, I looked for a way to port the project straight into the existing Gateware workspace. Unfortunately, for whatever reason, CodeBlocks has no built-in way to import one project into another which meant that I had to create a new blank project and then add and edit the files individually. This was very time consuming because of the sheer amount of options that had to be set. Many times I was sure I was done only to find another change somewhere I had overlooked in the stand-alone that I had not mimicked in the new project.
This process repeated itself almost exactly when I began integrating the XCode projects. I was even less familiar with this IDE but I got lucky and it ended up not taking any longer than the CodeBlocks integration. Really the solution besides spending lots of extra time in the IDE was going back and forth from stand-alone tests project settings to the newly created test project settings and making sure they matched up in every case. This was difficult in XCode and CodeBlocks because these IDE's do not support having multiple instances of themselves up like Visual Studios does. At the end of the day, I got both projects integrated and by the end of the week I was only about three days behind where I expected to be, which isn't a terribly unmanageable gap. Even though I was unclear of my expectations for week one, I was able to overcome the extra work by staying on task and working a little extra.
Friday, May 19, 2017
CMake and iOS Programming
So, CMake and iOS development can be a handful. While generating a XCode for iOS development, CMake leaves out a lot of settings. Working on those settings afterward can be frustrating and will take some time. It is through the CMakeLists.txt where all the breakthroughs happen as we can change all these settings through it and it's variables. The main problem I've actually encountered were the signing of the application. Since iOS development needs to use the app store for development. The application needs to be signed in order to be built and pushed to a device. The next problem following this is that in order to get an application signed, you need to be a certified iOS developer. With the linking of both the certifications and profiles to the application comes the hair pulling thought of "Why do I have to do this?" The current error that plagues me is just an incorrect signature.
Monday, May 15, 2017
Merging and Testing
Month Two: Week Two
This week, after completing the merging of the unit tests and the main repository, my main task was to begin the test-driven development side of our project. This means I was tasked with going into the unit tests and adding in my new GWindowTests file. In this file I will utilize the interface I wrote for GWindow to create tests for each function that will prove the library is functioning correctly.
The main issue I encountered was a flawed understanding of the Broadcaster / Listener we are using to communicate operating system messages to the end-user. I understood that my GWindow was a broadcaster and the end-user would derive their own listener from our GListener interface, but I didn't understand how the messages were actually being generated and sent. I needed to find a way to test the messaging system of my library, but without this knowledge I really had no idea how to go about it.
I started by looking at the interface my GWindow is derived from, the GBroadcasting interface. It has a RegisterListener function which only adds the id of the listener to a map; I couldn't see anything really about messages or sending or receiving. Next I checked the OnEvent function of the GListener which is run every time the Listener receives a message. I saw within this function the Listener was reacting to GBufferedInput events based on the id of the event passed in. This gave me a hint to go one step further and figure out where OnEvent is actually being called. Because of the parameters of OnEvent, I knew that message had to be sent from whoever was using this function.
Turns out the real cause of the trouble was that a file called GBI_callback.cpp was hidden inside the external dependencies drop-down in one of the many projects in our solution. I had never seen this file before, but it turns out this file actually holds the WndProc for GBufferedInput which captures all the Win32 messages sent to the broadcaster. At this point I saw that the Win3I2 message was being translated into our custom Gateware messages and THEN sent off to each registered Listener with the OnEvent function. Using this knowledge, I added my own if statement that is only true if the sending interface is my GWindow. From here I just increment a simple number to check if the window is maximized or not. At this point I have completely completed my test cases and am moving on to porting the tests to Linux and Mac and starting development.
This week, after completing the merging of the unit tests and the main repository, my main task was to begin the test-driven development side of our project. This means I was tasked with going into the unit tests and adding in my new GWindowTests file. In this file I will utilize the interface I wrote for GWindow to create tests for each function that will prove the library is functioning correctly.
The main issue I encountered was a flawed understanding of the Broadcaster / Listener we are using to communicate operating system messages to the end-user. I understood that my GWindow was a broadcaster and the end-user would derive their own listener from our GListener interface, but I didn't understand how the messages were actually being generated and sent. I needed to find a way to test the messaging system of my library, but without this knowledge I really had no idea how to go about it.
I started by looking at the interface my GWindow is derived from, the GBroadcasting interface. It has a RegisterListener function which only adds the id of the listener to a map; I couldn't see anything really about messages or sending or receiving. Next I checked the OnEvent function of the GListener which is run every time the Listener receives a message. I saw within this function the Listener was reacting to GBufferedInput events based on the id of the event passed in. This gave me a hint to go one step further and figure out where OnEvent is actually being called. Because of the parameters of OnEvent, I knew that message had to be sent from whoever was using this function.
Turns out the real cause of the trouble was that a file called GBI_callback.cpp was hidden inside the external dependencies drop-down in one of the many projects in our solution. I had never seen this file before, but it turns out this file actually holds the WndProc for GBufferedInput which captures all the Win32 messages sent to the broadcaster. At this point I saw that the Win3I2 message was being translated into our custom Gateware messages and THEN sent off to each registered Listener with the OnEvent function. Using this knowledge, I added my own if statement that is only true if the sending interface is my GWindow. From here I just increment a simple number to check if the window is maximized or not. At this point I have completely completed my test cases and am moving on to porting the tests to Linux and Mac and starting development.
Friday, May 12, 2017
Android, the headache
Android is an operating system that many phones use. From Samsung Galaxies to Samsung Note Tablets. This makes Android a largely used platform which means it should be heavily supported, right? Wrong. There is currently only 2 IDEs that are well-known and stable for developing on the Android system; Android Studio and Eclipse. Both of these are highly acclaimed and are mostly used for developing for Android. In order to use them though, both of them need another package though which is the android sdk. Android Studio comes with the sdk in its base install while eclipse android needs it to be installed with it. Now, after the sdk is installed and located by both of these IDEs, the true challenge emerges. Android uses the programming language java which is fine as java is an established language that has been used for a long time. What doesn't use java is the toolset that the Gateware team is making which there lies the problem. In order to make the toolset work with either IDE, we need to convert the java into C/C++. To convert java to C on either IDE, a package called android NDK must be installed. Only after both of these are done could a person work using C or C++ in order to work on Android. My problem is not coding in either language but to set up either IDE to be in this state using the CMake system. CMake can not install the sdk, nor the ndk, nor does it currently generate either Android Studio or Eclipse Studio projects. So, where do we go from here? That is the question soon to be answered as of all of this information was researched just this week.
Friday, May 5, 2017
Second Month, 1st week: Cmake Linux and Mac standalone
This week, worked on mac and Linux standalone system. The Linux system is working currently off of a console line system using curse CMake GUI. At the moment, the Linux system produces a Codeblocks - Unix files.The Mac system is currently running the CMake GUI system to build the system files. All of them are currently using the same source files and all of them are based on .cpps and C++ programming. Both CMake systems are working perfectly fine with the GUI systems. Working on writing a multi-platform CMake text file and cache that can run on all the systems without being changed. Plans after that are to make all of these files based on the console/terminal windows and away from the GUI systems.
Month Two, Week Two
Issues With Merging Unit Test and Main Development Repository
Author: Nic Russell
Posted: 5 May 2017
My first task this week was to incorporate our Unit Tests from our Test Suite into our main Gateware repository so that the tests are closer to the source code they depend on. Also, this will allow us to automatically build the Unit Tests after each build of the libraries which will ensure our tests and libraries are always up to date with each other.
The issue at the moment is that the library and include directories have changed significantly because of the new file structure of the Gateware repository. The Visual Studio solution was not looking in the correct place for the libraries once they were built and therefore could not build its own source code. I have never had so many separate projects with their own build settings and esoteric preferences in the same solution before, and it is difficult to keep them all in order.
The problem is that the Gateware repo was never designed to have another solution added to it, so the file structure has become a little muddled and I am still working with it to try and find a stable, easy to navigate structure. One issue I had was with the #include directories. The new structure of the repo made the old #include directory path deprecated, requiring me to remove some "..\..\" to get the path to look in the right repository. I then had to use more relative pathing in the source code itself to fix the #include path.
The next issue will be almost certainly be solved somewhere in the project settings, because the error I am currently getting is that the file "Gfile.lib" cannot be opened. First, I checked the lib directories and saw that the relative pathing was looking much too far back into the repository, to the point where it was looking for .lib's on my desktop. After taking out a few "..\..\" I was sure the path was correct because I could see the necessary .lib's and .dll's inside the folder I pathed to. However, The error was still occurring, so I began meticulously checking the Test Suite preferences to make sure any changes there were reflected in the new Gateware repo. After that, the error was still occurring. I have since added additional lib paths in the preferences. I started taking out .lib's and .dll's from the working Test Suite to try to mimic the error in the working repo, which I was able to do. The error would occur when the Library Directory preference was not set correctly, meaning it could not find the .lib. However, the current Library Directory IS looking at the correct .lib's, so at the moment I am a little lost.
As I keep working on this I plan on trying to try using preprocessor definitions to set up the lib paths and hopefully that will be more explicit linking and the project will find the correct libs.
Issues With Merging Unit Test and Main Development Repository
Author: Nic Russell
Posted: 5 May 2017
My first task this week was to incorporate our Unit Tests from our Test Suite into our main Gateware repository so that the tests are closer to the source code they depend on. Also, this will allow us to automatically build the Unit Tests after each build of the libraries which will ensure our tests and libraries are always up to date with each other.
The issue at the moment is that the library and include directories have changed significantly because of the new file structure of the Gateware repository. The Visual Studio solution was not looking in the correct place for the libraries once they were built and therefore could not build its own source code. I have never had so many separate projects with their own build settings and esoteric preferences in the same solution before, and it is difficult to keep them all in order.
The problem is that the Gateware repo was never designed to have another solution added to it, so the file structure has become a little muddled and I am still working with it to try and find a stable, easy to navigate structure. One issue I had was with the #include directories. The new structure of the repo made the old #include directory path deprecated, requiring me to remove some "..\..\" to get the path to look in the right repository. I then had to use more relative pathing in the source code itself to fix the #include path.
The next issue will be almost certainly be solved somewhere in the project settings, because the error I am currently getting is that the file "Gfile.lib" cannot be opened. First, I checked the lib directories and saw that the relative pathing was looking much too far back into the repository, to the point where it was looking for .lib's on my desktop. After taking out a few "..\..\" I was sure the path was correct because I could see the necessary .lib's and .dll's inside the folder I pathed to. However, The error was still occurring, so I began meticulously checking the Test Suite preferences to make sure any changes there were reflected in the new Gateware repo. After that, the error was still occurring. I have since added additional lib paths in the preferences. I started taking out .lib's and .dll's from the working Test Suite to try to mimic the error in the working repo, which I was able to do. The error would occur when the Library Directory preference was not set correctly, meaning it could not find the .lib. However, the current Library Directory IS looking at the correct .lib's, so at the moment I am a little lost.
As I keep working on this I plan on trying to try using preprocessor definitions to set up the lib paths and hopefully that will be more explicit linking and the project will find the correct libs.
Subscribe to:
Posts (Atom)