ezzieyguywuf wrote: ↑Thu Mar 29, 2018 9:12 pm
how would you suggest i improve this?
Compiling a branch and being able to start testing would be a good start. But this still would expose your work to only a handful of FreeCAD users/developers. Therefore i guess it comes down to binaries for different platform. There i guess is just no way around that.
In addition @realthunder and @ickby approach started to align. It took at least a year for that to happen. I don't want to push you in that direction. As i feel you are entitled to work on your ideas. But from upstream point of view it would likely make sense if 3 developers would work on the same effort in FreeCAD 0.18 (and likely FreeCAD 0.19 development cycle). This is just such huge effort. And if we want to start using anything remotely useful in next two years. It would likely take 3 developers at minimum to make it happen. More developers working on the same goal would likely enable each developer to contribute something unique to the final solution. Therefore maybe it wouldn't end up exactly as you have envisioned it. But that might end up being a good thing.
ezzieyguywuf wrote: ↑Thu Mar 29, 2018 9:12 pm
how would you suggest i improve this?
Compiling a branch and being able to start testing would be a good start. But this still would expose your work to only a handful of FreeCAD users/developers. Therefore i guess it comes down to binaries for different platform. There i guess is just no way around that.
In addition @realthunder and @ickby approach started to align. It took at least a year for that to happen. I don't want to push you in that direction. As i feel you are entitled to work on your ideas. But from upstream point of view it would likely make sense if 3 developers would work on the same effort in FreeCAD 0.18 (and likely FreeCAD 0.19 development cycle). This is just such huge effort. And if we want to start using anything remotely useful in next two years. It would likely take 3 developers at minimum to make it happen. More developers working on the same goal would likely enable each developer to contribute something unique to the final solution. Therefore maybe it wouldn't end up exactly as you have envisioned it. But that might end up being a good thing.
well,let me know if my instructions don't work. if they do, then at least part one of your proposal is accomplished. regarding binaries for different platforms, I believe it is a bit premature for that. Currently this solution is still in the early phases of development, and therefore I am merely looking for input from other developers. It is not really ready for rigorous user testing.
I'm not averse to switching directions. if realthunder 's approach is the better one I can support that. however, before abandoning my own work, I'd appreciate at least a cursory review from ay least ickby and realthunder. if we're the only folks working on this problem, and we can all agree on a single direction, then I will support that wholeheartedly.
ezzieyguywuf wrote: ↑Thu Mar 29, 2018 9:42 pm
well,let me know if my instructions don't work. if they do, then at least part one of your proposal is accomplished.
On Ubuntu 16.04 this is the first problem (due to older CMake):
I'm not averse to switching directions. if realthunder 's approach is the better one I can support that. however, before abandoning my own work, I'd appreciate at least a cursory review from ay least ickby and realthunder. if we're the only folks working on this problem, and we can all agree on a single direction, then I will support that wholeheartedly.
Note that i personally don't have an issue with all 3 of you developing different solutions. Especially in prototyping phase. That makes much sense. And i am not saying you shouldn't proceed to follow your ideas. Comment was more geared towards if we are talking about upstream work. And to get something working in foreseeable future. There is where a common goal likely does make sense. And indeed @realthunder and/or @ickby will hopefully get involved. And evaluate your proposal. At some point in the future. I guess once @realthunder shares his work. Likely that will interest @ickby. As the proposal and work done should generally speaking be aligned. And you already shared your work and plans. Therefore i guess we are getting there.
What version of cmake do you have? I don't think I use any fancy features, I can probably lower the minimum version. I just set it to the version I had installed. you can change that line in the top of the CMakeLists.txt file (the first one) and retry.
ezzieyguywuf wrote: ↑Fri Mar 30, 2018 4:42 pm
What version of cmake do you have? I don't think I use any fancy features, I can probably lower the minimum version. I just set it to the version I had installed. you can change that line in the top of the CMakeLists.txt file (the first one) and retry.
I use version 3.5.1. OK i changed the version number manually and followed the instructions:
Unfortunately things stop again at compiling OccWrapper step. It looks like Google Test library would be needed? I commented out the test folder part from CMakeLists altogether. Compiling OccWrapper was possible but unfortunately TopoManagers didn't want to play along after. Therefore to first make things clearer. What is the situation with Google Test library dependency?
Im so embarrassed you’re having such problems with my code base!
You can get rid of all the googletest stuff in the CMakeLists.txt it is used for unit testing. I don’t know why you’re having problems with it, it could be I forgot to add the googletest directory to my git repository.
Is the googletest the only issue you’ve had with compilation?
ezzieyguywuf wrote: ↑Fri Mar 30, 2018 10:22 pm Im so embarrassed you’re having such problems with my code base!
It would i guess be too easy if it would just work. Where would be the fun in that?
You can get rid of all the googletest stuff in the CMakeLists.txt it is used for unit testing. I don’t know why you’re having problems with it, it could be I forgot to add the googletest directory to my git repository.
Is the googletest the only issue you’ve had with compilation?
Yes it is missing. I was able to "fix" this part by leaving the whole test folder out when compiling OccWrapper. But i guess by compiling OccWrapper without the unit tests. After when compiling TopoManagers. It looks like TopoManagers doesn't like the OccWrapper compiled without unit tests. And TopoManagers fails to compile as a result. This is it for today. Shared my current understanding. Will likely try again tomorrow. To see if further progress can be made.
I also get the error that a cmake file is missing in the googletest dir. But it looks like the directory is empty - so maybe you just need to add the files to git?
when I get home tonight, I'll fix the googletest problem. I'll also try to download a fresh clone and compile (like I should have done to begin with!) to ensure everything works as expected. (this is what happens when you let mechanical engineers code: they make silly mistakes like this )
I'm shocked at triplus' comments that TopoManagers seems to "not like" that OccWrapper was compiled without googletest. it shouldn't matter. this suggests there's something more nefarious wrong with the build system I've set up.
all the more reason for me to download a fresh clone and try compiling from scratch.
Sorry about all the bother: please know that I'm truly embarrassed and have taken this as a learning opportunity (which in fact my involvement with freecad was always intended to be). I should hopefully not make these types of errors in the future.
Im so embarrassed you’re having such problems with my code base!