Re: Passing variables to a Makefile
Dear all, Many thanks everybody for your answers. Le Thu, Oct 11, 2007 at 12:51:26PM +0200, Daniel Leidert a écrit : Am Donnerstag, den 11.10.2007, 10:52 +0900 schrieb Charles Plessy: in a package I prepare, there is the following line in a source/Makefile: CPPFLAGS=-O3 -funroll-loops -march=i686 -mfpmath=sse -msse -mmmx This is obviously not convenient for building on many platforms, so I decided to override it with the following command in debian/rules: CPPFLAGS='$(CFLAGS)' $(MAKE) --environment-overrides --directory=source $(MAKE) -C source CPPFLAGS='$(CFLAGS)' Le Thu, Oct 11, 2007 at 08:16:17AM -0400, Justin Pryzby a écrit : On Thu, Oct 11, 2007 at 10:52:03AM +0900, Charles Plessy wrote: Dear mentors, in a package I prepare, there is the following line in a source/Makefile: CPPFLAGS=-O3 -funroll-loops -march=i686 -mfpmath=sse -msse -mmmx CPPFLAGS is for the C PreProcessor. For the sake of cleanness, I will use: $(MAKE) --directory=source CPPFLAGS='' CFLAGS='$(CFLAGS)' With this, I erase the arch-specific options which should anyway not be in CPPFLAGS, and I use the Debian CFLAGS instead. I will benchmark the program later to see if O3 is really needed... Have a nice day, -- Charles Plessy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passing variables to a Makefile
Charles Plessy schrieb: Dear mentors, in a package I prepare, there is the following line in a source/Makefile: CPPFLAGS=-O3 -funroll-loops -march=i686 -mfpmath=sse -msse -mmmx This is obviously not convenient for building on many platforms, so I decided to override it with the following command in debian/rules: CPPFLAGS='$(CFLAGS)' $(MAKE) --environment-overrides --directory=source However, I am quite unexperienced with makefiles, and my gut feeling tells me that I may be doing something wrong... Can somebody tell me ? ( Just in case one wants to see more context, I have uploaded the package on mentors: http://mentors.debian.net/debian/pool/main/d/dialign-t/dialign-t_0.2.2-1.dsc It is work in progress unsuitable for anyghing else! ) Have a nice day, Hi Charles, better use a patch system like dpatch for it. Don't modify the source, write a patch for it! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passing variables to a Makefile
2007/10/11, Charles Plessy [EMAIL PROTECTED]: Dear mentors, in a package I prepare, there is the following line in a source/Makefile: CPPFLAGS=-O3 -funroll-loops -march=i686 -mfpmath=sse -msse -mmmx This is obviously not convenient for building on many platforms, so I decided to override it with the following command in debian/rules: CPPFLAGS='$(CFLAGS)' $(MAKE) --environment-overrides --directory=source However, I am quite unexperienced with makefiles, and my gut feeling tells me that I may be doing something wrong... Can somebody tell me ? It seems OK for me, I usually do it that way too. You can also alternatively override the variable sending it as a parameter for make: $(MAKE) -C source CPPFLAGS='$(CFLAGS)' But in my opinion both ways are equivalent in this case. I did not have time to have a look at the package anyway, so I haven't tested it. I'm quite too busy these days, sorry. Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passing variables to a Makefile
Am Donnerstag, den 11.10.2007, 10:52 +0900 schrieb Charles Plessy: in a package I prepare, there is the following line in a source/Makefile: CPPFLAGS=-O3 -funroll-loops -march=i686 -mfpmath=sse -msse -mmmx This is obviously not convenient for building on many platforms, so I decided to override it with the following command in debian/rules: CPPFLAGS='$(CFLAGS)' $(MAKE) --environment-overrides --directory=source $(MAKE) -C source CPPFLAGS='$(CFLAGS)' However, I am quite unexperienced with makefiles, and my gut feeling tells me that I may be doing something wrong... Can somebody tell me ? ( Just in case one wants to see more context, I have uploaded the package on mentors: http://mentors.debian.net/debian/pool/main/d/dialign-t/dialign-t_0.2.2-1.dsc It is work in progress unsuitable for anyghing else! ) One issue in debian/rules: + install -o 755 source/dialign-t debian/dialign-t/usr/bin/ + dh_install conf/* usr/share/dialign-t You mean `install -m'. -o sets the ownership. However, you can safely use dh_install here, because dh_fixperms (binary-arch target) will set the right permissions. You further don't need to run dh_installdirs for directories, used in dh_install. The latter will automatically care about non-existing directories, like usr/share/dialign-t. You only need to create the diretories first, if you e.g. use `install' instead of dh_install or of you want to create links there. Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passing variables to a Makefile
On Thu, Oct 11, 2007 at 12:51:26PM +0200, Daniel Leidert wrote: Am Donnerstag, den 11.10.2007, 10:52 +0900 schrieb Charles Plessy: about non-existing directories, like usr/share/dialign-t. You only need to create the diretories first, if you e.g. use `install' instead of dh_install or of you want to create links there. I guess this is handled too by install -D. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passing variables to a Makefile
On Thu, Oct 11, 2007 at 10:52:03AM +0900, Charles Plessy wrote: Dear mentors, in a package I prepare, there is the following line in a source/Makefile: CPPFLAGS=-O3 -funroll-loops -march=i686 -mfpmath=sse -msse -mmmx CPPFLAGS is for the C PreProcessor. So it's supposed to have things like -Iinclude -DFOO=BAR. CFLAGS is for the C compiler itself, so it's supposed to have things like -O3 -funroll-loops -std=gnu99 -Wall -Wextra. But it only matters if you're using the implicit rules and the binaries are built from multiple source files or are otherwise compiled and linked in separate invocations. BTW there's LDFLAGS too for linker options like -Wl,-soname,libfoo.so.1 -Wl,-O2 (here it's assumed that LD=gcc thus the -Wl, thing). I think that Debian packages shouldn't have subarch-specific options on any arch, since the same binaries may/(have to be able to) be run on variation on that arch. In the case of i386, the binaries have to be able to run on a real 386 [0]. I think all the arch options here will (maybe) cause the binary to fail on such a machine. Justin [0] My understanding is that the packaged kernels don't support 386 but with a software emulation of some math instruction patched in, 386 is advertised as being supported with binary packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passing variables to a Makefile
Am Donnerstag, den 11.10.2007, 08:15 -0400 schrieb Justin Pryzby: On Thu, Oct 11, 2007 at 12:51:26PM +0200, Daniel Leidert wrote: Am Donnerstag, den 11.10.2007, 10:52 +0900 schrieb Charles Plessy: about non-existing directories, like usr/share/dialign-t. You only need to create the diretories first, if you e.g. use `install' instead of dh_install or of you want to create links there. I guess this is handled too by install -D. It is. But many users miss it and then the package FTBFS because of the non-existing target directory. However, install is only useful, if you have to rename the source or if you have to set special permissions, not handled by dh_fixperms. I often miss the possibility to use this dehelper script with: dh_fixperms $target $permissions IMHO this would reduce the necessity to use chmod or install in debian/rules. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passing variables to a Makefile
On Thu, 11 Oct 2007 08:16:17 -0400, Justin Pryzby [EMAIL PROTECTED] said: On Thu, Oct 11, 2007 at 10:52:03AM +0900, Charles Plessy wrote: Dear mentors, in a package I prepare, there is the following line in a source/Makefile: CPPFLAGS=-O3 -funroll-loops -march=i686 -mfpmath=sse -msse -mmmx CPPFLAGS is for the C PreProcessor. [...] Possibly they meant CXXFLAGS, which is for the C++ compiler? [...] [0] My understanding is that the packaged kernels don't support 386 but with a software emulation of some math instruction patched in, 386 is advertised as being supported with binary packages. Support for 386 chips was officially dropped in Sarge [1]. I think it was because they weren't able to get the software emulation working without too much effort. But packages should still run on a 486 [2]. [1] http://www.debian.org/releases/stable/i386/ch02s01.html.en#id2530465 [2] But it is OK to include support for the extra instructions (MMX, SSE, etc.), as long it checks that they are supported before using them. -- Hubert Chathi [EMAIL PROTECTED] -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Passing variables to a Makefile
Dear mentors, in a package I prepare, there is the following line in a source/Makefile: CPPFLAGS=-O3 -funroll-loops -march=i686 -mfpmath=sse -msse -mmmx This is obviously not convenient for building on many platforms, so I decided to override it with the following command in debian/rules: CPPFLAGS='$(CFLAGS)' $(MAKE) --environment-overrides --directory=source However, I am quite unexperienced with makefiles, and my gut feeling tells me that I may be doing something wrong... Can somebody tell me ? ( Just in case one wants to see more context, I have uploaded the package on mentors: http://mentors.debian.net/debian/pool/main/d/dialign-t/dialign-t_0.2.2-1.dsc It is work in progress unsuitable for anyghing else! ) Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
