Menu
▾
▴
opensync-devel
|
From: Quentin D. <que...@gm...> - 2010-10-21 07:22:43
|
On Monday 18 October 2010 19:31:15 opensync-devel- re...@li... wrote: > Date: Mon, 18 Oct 2010 18:36:45 +0200 > From: Michael Banck <mb...@gm...> > Subject: Re: [Opensync-devel] Two brakes in libopensync > To: ope...@li... > Message-ID: > <201...@ni...> > Content-Type: text/plain; charset=us-ascii > > On Mon, Oct 18, 2010 at 05:45:28PM +0200, Quentin Denis wrote: > > 1. The cmake macro MacroEnsureOutOfSourceBuild prevents from building > > the sources within the source directory. OpenSync is the first source I > > know that uses this annoying macro. Why? It makes the compilation > > process just more painful, removing this macro will make things much > > easier. As far as I have experienced, building outside the source > > directory has no advantage, so why forcing it? > > For the record, building out of the source tree is usual practise in > cmake-based projects anyway, though I am not aware of other projects > enforcing this. One of the advantages is that you can easily clean up > your build tree by just removing it. Well, as far as I have experienced, even building outside the tree was in some case not possible (i.e. cmake ../file-sync). You probably then have to set a series of env variables, but IMHO these are exaggerated measures. I would suggest to remove this constraint if there is no major counter-argument. > > 2. the __sun statement in opensync.h causes frequent troubles: > > [ 1%] Building CXX object > > libqopensync/CMakeFiles/qopensync.dir/callbackhandler.o > > cc1plus: warnings being treated as errors In file included from > > /home/murz/temp/2010-09/sync/kitchensync/libqopensync/callbackhandler.cpp > > :22: /usr/include/libopensync1/opensync/opensync.h:52: error: "__sun" is > > not defined > > > > > > How can we fix this issue? I do it by removing the lines 52-54 in > > opensync.h, but this is only my simple workaround. > > What compiler do you use? Maybe very recent versions of gcc are more > picky about these kind of if/then/else macro structures. I am using gcc 4.5.0. This issue concerns many users out there and it is really not a clean and nice solution to tell them to edit the opensync.h file. What can we do about that? In the worst case scenario I would suggest to remove that macro. -Quentin |
|
From: Graham C. <g+o...@co...> - 2010-10-21 14:00:20
Attachments:
environ2
|
On Thursday 21 October 2010 08:22:21 Quentin Denis wrote: > Well, as far as I have experienced, even building outside the tree was in > some case not possible (i.e. cmake ../file-sync). You probably then have > to set a series of env variables, but IMHO these are exaggerated measures. > I would suggest to remove this constraint if there is no major > counter-argument. I can't comment on whether the restriction is a good thing. I vaguely remember when it was introduced and that whoever did it had what they believed to be good reasons but I have no idea what they were. For your information, I have attached (if this list accepts attachments -- if not, drop me an email if you want me to send it) the script that I "source" in order to set up the env variables for my development builds. Note that this was derived from someone else's script a long time ago -- apologies that I cannot remember who supplied the original. In my case, I have an "opensync" directory which is a parent of the various svn checkout directories for the components and is also a parent for the build directory. I can also send you, if you want, the scripts and rules files I use for the builds which create debian packages for Maemo. They work slightly differently. Graham |
|
From: Ian M. <ian...@ca...> - 2010-10-21 14:08:33
|
>> > 2. the __sun statement in opensync.h causes frequent troubles: >> > [ 1%] Building CXX object >> > libqopensync/CMakeFiles/qopensync.dir/callbackhandler.o >> > cc1plus: warnings being treated as errors In file included from >> > /home/murz/temp/2010-09/sync/kitchensync/libqopensync/callbackhandler.cpp >> > :22: /usr/include/libopensync1/opensync/opensync.h:52: error: "__sun" is >> > not defined >> > >> > >> > How can we fix this issue? I do it by removing the lines 52-54 in >> > opensync.h, but this is only my simple workaround. >> >> What compiler do you use? Maybe very recent versions of gcc are more >> picky about these kind of if/then/else macro structures. > I am using gcc 4.5.0. This issue concerns many users out there and it is > really not a clean and nice solution to tell them to edit the opensync.h file. > > What can we do about that? In the worst case scenario I would suggest to > remove that macro. > I imagine kitchensync is being compiled with the -Wundef option Revision 6150 contains the patch from ticket http://www.opensync.org/ticket/1263 that fixes this problem Do people think -Wundef be added to the Hacking build flags? Ian |
|
From: Emanoil K. <del...@ya...> - 2010-10-21 14:55:49
|
Hi, --- On Thu, 10/21/10, Ian Martin <ian...@ca...> wrote: I imagine kitchensync is being compiled with the -Wundef option Revision 6150 contains the patch from ticket http://www.opensync.org/ticket/1263 that fixes this problem Do people think -Wundef be added to the Hacking build flags? I'm getting this warning when compiling plugins too, not just kitchensync. I'm using debian sid with whatever default c/c++ version there. And there is no -Wundef explicitely set in the cmake files, so may be compiler related. regards |
Thanks for helping keep SourceForge clean.
X