Forum Replies Created
-
Posts
-
its a graphics based program, so I can’t really reduce it. I will make a small text test program though and see what happens.
The version of Raspbian is the latest Stretch version,and Visual GDB is uptodate, I’d rather not use other ssh clients, since I am attempting to use VisualGDB and dont’ want to be switching things around.
Hi
No its building on the target and GDB on the Raspberry
Running without debug produces some odd results (I’ve never used that option before) Graphics don’t appear, and errors get reported but the project does its best to run, but even so keys still do not register in the Stdin
I find the new smartty to be unreliable, constantly popping up windows and warning of errors I don’t understand… but I can use a standard smarttty. Running from the standard smart terminal, navigating to the debug folder and ./ starting it, the project fires up, all graphics and other info in place, but again reports no keys.
Going to the Raspberry itself, in the GUI opening the Debug folder and executing in terminal. I get my project up and running with graphics as expected, and the terminal output on the Raspberry reports the stdin keys are being read and reporting presses….kinda odd?
And repeating the process in a terminal window on the Raspberry, navigating to the debug folder and ./ running the project, fires it up and again keys work and output is reported in the terminal window
any ideas?
it would appear that VisualGDB is only able to identify the Android SDK directory from the presence of SDK Manager.exe, but Android studio does not itself install that when it sets up its tools and platforms directory. So while it eventually is possible to set up Android Studio, Visual GDB can’t appear to do much with the project it imports as it can’t set up the Android SDK dirs without that SDK Manager.
I’m really quite lost and quite tired of this, it simply does not work as it should.
nope, without doubt this has been the most painful 8 hours or so I’v eever experienced trying to get anything to work. Finally Android studio builds a working project, but then Visual GDB didn’t give me any option to import…… The attempt to manually locate the SDK/NDK is met with a lack of SDKManager.exe so it cant locate it, even though Android studio spent the best part of an hour installing the sdk and the preferred platforms.
What should be a simple, press of a Start a project for me, turned into a living hell…. I can’t work with this.
please let me know when you manage to actually get a project to start up so I can do a hello world in less than 5 mins, until the, I can’t take the stress.
Well after much swearing and stress I got Android Studio to install, and download multiple version of the SDK but attempting to import it threw up errors
I created the default app in Android studio and confirmed it built and ran (on emulator) quit, ad then fired up Visual Studio 2017 to import a project as described, but the import did not go smoothly
first it said it could not detect the compiler version from my make file, and I would need to specify build arguments e.g NDK_MODULE_PATH
I was forced to ignore and continue
The project then loads and creates itself, but the Toolchain test fails with Cannot query the value of TARGET_CXX please double check you setting
I again had to ignore as I have no way to set this during the import
The same error occurs again ignored
I then get to a project with my app but of course it does not build, giving me a range of issues,
incluing the NDK 64bit build bug, but when I look at the init.mk file the fix is already in place….
So…basically import does not seem to get me to a working build on VisualGDB
Can you offer any advice?
Thanks for the reply,
in the end I discovered it was due to me including /usr/linux, which another config needed.. it now compiles fine.
Ah, sadly my understanding of linux means I have no clue how to do that, but I appreciate its not a Visual GDB issue, I’ll try to locate a linux guru to assist me, thanks for the advice.
Aha…there it is right in front of my all this time, thanks
unfortunatly this does not solve my issue, in fact it creates new ones, my build runs, but no longer opens an X11 or GLES2.0 context to render to.
Any idea why that might be? *
*This could be normal linux behaviour, I’m honestly not a linux coder so things like this are quite confusing to me.
I don’t really want to convert my non ms build…so we are at a stalemate. So best to just hand copy directory and lib names over.
If I’m honest I don’t have good defend-able reasons for preferring GCC on remote builds, other than I find the set up and addition of parameters much easier with GCC, and in turn its easier to explain the workings to my students. MS build requires I have to go into VS properties to alter some things when I need to change the build, GCC tends to have it all accessible through VisualGDB properties. When all said and done, I am not someone who jumps to change too quickly even if there are benefits, GCC on target is familiar and clear to me, I like the error and warning levels more and I am actually quite interested in how long files take to compile to demonstrate good code/file structure.
MSbuild hides too much even though I am sure it will be faster and have more benefits (like allowing VS dependency to work). Ironically I much prefer MSbuild for my PC based cross compiles. I guess its just down to preference and taste.I will try it though…promise.
Hi
ok thanks for explaining the configs. I won’t delete anything just in case things break
The copying of settings only works if you are using the add to current config, I prefer to use GCC for my on target builds, and MSbuild for my Remote builds, but creating a new MSbuild, of course sets up a blank list of settings. Is there a way to import and convert where needed the Gcc settings?
Thank you, yes indeed using the = to append the dir to the sysroot is much cleaner, also important to remember that MSbuild expects semi colons as seperators when you enter in the libs.
I do feel that if you are creating a new configuration in a project it should be possible to transfer your directory structure and library names to the new config as a default, could that be added.
A final question, When I create a new config, I find that I now have multiple configs for all my builds, including the on target ones, win32 and Visual GDB, why does the wizard produce these, I noticed if I deleted the win32 ones it had a catastrophic result, bu I find having so many configs generated when I only expect 3 (on target debug, on target release, cross debug) to be confusing?
A final comment, which I hope will help others
Sending assets is done via the Custom build step settings, actually quite painless once I found it. You can do it before the build
Also setting up an MSbuild config, rather than a GCC config is way easier, GCC is just too fussy, MSbuild, allows use of short lib filenames and had little issues getting it set up, though do be aware if where you deploy it, on the target, it defaults to /tmp I changed it to /tmp/obj and then let my assets transfer into /tmp
this is more compatible with an on target built file structures which assumes your obj is running in a debug folder allowing you to do a step ../ back then into your Resource directories.I can now easily swap between on target build and cross compile configurations as needed.
MSbuild is also blindingly fast compared to gcc
Sorry if this has been a strange incoherent set of posts 😀It would be nice if Sysprogs could provide some automation of converting an on target build to cross compile build, any chance we might see that or is it there and I missed it?
