lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Can we rename lmi.rc or lmi.cpp?


From: Vadim Zeitlin
Subject: Re: [lmi] Can we rename lmi.rc or lmi.cpp?
Date: Thu, 23 Jun 2011 12:57:19 +0200

On Thu, 23 Jun 2011 10:51:48 +0000 Greg Chicares <address@hidden> wrote:

GC> Please take a look at 'Makefile.am', which needs more work for two
GC> reasons. First, my old workaround:
GC>   foo.cpp --> foo.o
GC>   foo.rc  --> foo.rc.o [with '.rc' inserted in destination name]
GC> was distasteful,

 I wouldn't say this, it seemed like a natural solution to me. But the
trouble is that, tasteful or not, it didn't actually work. This file is not
actually a (GNU) make input file but automake input and while it has
similar syntax, it's not quite the same and, in particular, using foo.rc.o
didn't allow automake to find the correct object file for foo.rc source.

GC> What do you think of this proposed change?
GC> 
GC> Index: Makefile.am
GC> ===================================================================
GC> --- Makefile.am     (revision 5215)
GC> +++ Makefile.am     (working copy)
GC> @@ -204,7 +204,10 @@
GC>  if LMI_MSW
GC>  ## use old style suffix rule instead of the pattern one as automake only
GC>  ## recognizes the old style rules
GC> -.rc.o:
GC> +## Vadim--is that comment still applicable? and is this rule necessary,
GC> +## or does a builtin default rule suffice now that we're compiling
GC> +## 'foo.rc' to 'foo.o' instead of 'foo.rc.o'?
GC> +.o:
GC>     $(WINDRES) -I $(top_srcdir) $(WX_CPPFLAGS) $< $@

 It does need to be a suffix rule because this is how automake knows that
it needs to link with foo.o when foo.rc is used as a source, apparently. At
least I can definitely confirm that it doesn't work without it, I tested.

GC>      lmi_wx_SOURCES += lmi_msw_res.rc
GC> @@ -217,10 +220,6 @@
GC>      $(GTK_LIBS) \
GC>      $(BOOST_LIBS) \
GC>      $(WX_LIBS)
GC> -if LMI_MSW
GC> -    lmi_wx_SOURCES += lmi_msw_res.rc
GC> -    lmi_wx_CXXFLAGS += -mwindows
GC> -endif

 Yes, this is definitely correct, apparently it was a result of some bad
merge.

 I can recheck that Makefile.am actually works in the trunk (so far I only
tested it on our local branch of LMI) and either commit these changes
directly to svn or post a tested patch here.

 Please let me know what, if anything, would you prefer,
VZ

reply via email to

[Prev in Thread] Current Thread [Next in Thread]