Quote:
Originally Posted by rbmj
Once you have debhelper and devscripts et al installed, it's not too bad. You won't be able to sign the packages, but everything else will work. Buildscripts is easy - just run ./debmake and it should work automatically. Beware, however, that that script will make the latest commit in the git repo, so you need to commit any changes before they will go into the package.
For the other packages, the basic workflow is this:
1. create or download/rename a pkgname_version.orig.tar.gz file. It should extract to pkgname-version.
2. extract this archive, and go into the the created source directory
3. If the source doesn't have a debian subdirectory, copy the debian subdirectory into the source from my git repo
4. run [il]debuild -us -uc[/il]. This will create but not sign the packages. If you want to sign the packages yourself you'll need to make a key and make a new changelog entry with the dch command, making sure that the name, nickname (you might have to add this in manually), and email match EXACTLY your key's info.
note that in order to not conflict with the packages that debian will build, many of the packages are named powerpc-wrs-vxworks-name. That's what you use for package name. Additionally, these directories don't have version numbers, so you either have to rename the directory or make a new copy of the repo.
As an exception, you need to add [il]-e WIND_BASE[/il] when you call debuild for gcc.
I highly suggest that you do your homework though. The debian buildsystem is very powerful, but it's not exactly simple, and there are a LOT of gotchas.
As far as your gcc error goes, looks like something's up with fixincludes (again). Double check to make sure that fixincludes is running, and if that doesn't work, look inside your gcc build directory (not top level, but the gcc build directory itself), find include-fixed, and look in there for sys/stat.h. Once you have determined that that file exists, look for a variadic macro for mkdir.
If that file does not exist, tell me which files do in the include-fixed directory.
EDIT: I'm looking at the way that you fixed WPILib. Good job on fixing all those constexpr issues, however we need to maintain compatibility with c++98. You probably need to test #if __cplusplus < 201103L and have a macro that selects the correct const-incantation for different versions of c++. My perspective is that we should strive for integration with upstream as much as possible (even if development is rather closed off) as I do not have or want to put in the time and energy necessary to maintain a full fork. This is why I worked so hard to get the patches merged in to GCC itself - so all those hacks were no longer necessary, and we weren't going after a moving target. And, to return to the point, there's no way that they'll accept any changes that break compatibility with c++98.
IF the community wants a more openly developed version of WPILib, OK. We can put in the work to make that happen if it's a goal (primarily meaning make it easy to integrate with ucpp and standard WindRiver. If we can react to bug reports on CD faster than upstream, then that might be a feature justifying a fork. However, as much as the long time between bugfixes and the secret development of WPILib irks me, I don't see a large enough demand to justify a fork.
|
Sounds good. I'll have to get working on the compatibility issue. I've fixed all the errors, and some of the warnings for WPILib with C++11. I can confirm that at least the memory management features of C++11 work on hardware as of tonight!
The C++11 only version of WPILib is here:
https://github.com/mcoffin/wpilib/tree/cxx11.
As for making sure we're backwards compatible, from what I've read, WPILib as it is
shouldn't compile under C++98 either, it's just a fluke that GCC is playing loose with the standards there. Therefore, I think that when making a fix, it would be best to avoid the initialization of static constant members that are floats/doubles from within the class declaration all together. I think that the next best solution would just be to put them in the constructor? That would work on both standards, whereas the constexpr fix defining them as expressions would only work for C++11.
EDIT: The contents of include-fixed are as follows. I'm going to re-start from scratch just in case I missed a flag somewhere that caused fixincludes to mess up, but here are the contents in case I get the error again:
Code:
limits.h
README
syslimits.h
EDIT 2: To anybody that's thinking of dealing with WPILib, I suggest adding the following flag in CMAKE_CXX_FLAGS to filter out all the deprecated string literal warnings. There's no way that anybody is going to go through the whole library and convert it to using std::string unless that have absolutely no life.
EDIT 3: Build error was just a fluke. I have no idea what happened. Deleted my build directory, reconfigured and it worked. That was pretty stupid on my part. Sorry for the hassle on that one.
EDIT 4: The virtual destructor warnings are legit. These are abstract classes with pure abstract methods, and the classes have derived classes. This means that if a derived class were to have an explicit destructor, it wouldn't be getting called. I'll be sure to fix those warnings in the next round of fixes.
EDIT 5: The master branch on my git repository should fix many of the compiler warnings for wpilib on C++98 as well. I haven't tested compatibility with old versions of GCC yet though. I did leave some unnecessary typedef's in there because I think that they, at some point, were necessary, so WindRiver's version of GCC might still want them and I don't want to break compatibility with it. The C++11 branch has these changes pulled in as well.