alo@kampi.hut.fi (Antti Louko) (03/03/89)
In article <238@yasc.PLA.CA.US> geoff@yasc.PLA.CA.US (Geoff Leach) writes: >Turns out there's a cure for this. Try "cake", posted to comp.sources.unix, >volume 12. Not only does it permit the user to program _all_ his/her own >rules, but it also permits the specification of dynamic dependencies. When I saw cake first time, it seemed just fine. But after a while I realized one thing. After that I haven't used cake anymore. Lets have an Cakefile: $ cat Cakefile vax: /dev/null cp /dev/null vax $ cake cp /dev/null 1 $ Funny, uh? If you have a SUN, replace "vax" with "sun". Try GNU make instead. It is more compatible with original make and it doesn't confuse variable names with file names.
djones@megatest.UUCP (Dave Jones) (03/04/89)
From article <20078@santra.UUCP>, by alo@kampi.hut.fi (Antti Louko): > > When I saw cake first time, it seemed just fine. But after a while I > realized one thing. After that I haven't used cake anymore. > > Lets have an Cakefile: > > $ cat Cakefile > vax: /dev/null > cp /dev/null vax > > $ cake > cp /dev/null 1 > $ > > Funny, uh? If you have a SUN, replace "vax" with "sun". > I gave up on cake also, but for different reasons.. I was trying to use it to keep up with making sub-files: specifically, entries in an archive.a. I never did get it to work. Finally decided that I was understanding things correctly, but cake was broke. Anyhow.. The example you gave demonstrates a problem with cpp, and cake runs its input through cpp. Try compiling the following C one-liner on your vax: int vax; I will not compile, because cpp translates it into int 1; "vax" is predefined by cpp to be "1". Oh well. The reason they define sun, or vax, or whatever, is for those #ifdef thingies, like #ifdef sun some silly code #else some other silly code #endif sun I can't think of any way to do it better, without drasticly changing the way cpp works. What's needed is some way to limit the scope of #defines, so that the above could be done something like this: #with <machine_type.h> # ifdef sun some silly code # else some other silly code # endif sun #endwith <machine_type.h> int sun; But cpp was not specked very well to begin with, and now we are pretty much stuck with it the way it is.
gwyn@smoke.BRL.MIL (Doug Gwyn ) (03/05/89)
In article <2712@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes: >The example you gave demonstrates a problem with cpp, and cake >runs its input through cpp. Which is yet another error in the implementation of "cake". /lib/cpp, when it exists, is not intended to be used except via "cc", and there is no guarantee that /lib/cpp (or "cc -E") will even exist.
leo@philmds.UUCP (Leo de Wit) (03/05/89)
In article <20078@santra.UUCP> alo@hut.fi (Antti Louko) writes: |When I saw cake first time, it seemed just fine. But after a while I |realized one thing. After that I haven't used cake anymore. | |Lets have an Cakefile: | |$ cat Cakefile |vax: /dev/null | cp /dev/null vax | |$ cake |cp /dev/null 1 |$ | |Funny, uh? If you have a SUN, replace "vax" with "sun". How about undefining some predefined macros? This one is for Ultrix 2.0: /lib/cpp -Uunix -Ubsd4_2 -Uultrix -Uvax -U__LINE__ -U__FILE__ makefile Of course, if you want to use those names also for conditional make rules inclusion, you're out of luck. But so you are if you try to declare 'vax' as a variable in a C program! From this viewpoint and to enhance cakefile portability I would prefer to leave them #defined and refrain from using targets like 'vax', etc. (B.T.W. I found those macros using 'strings -2 /lib/cpp') Leo.
prc@maxim.ERBE.SE (Robert Claeson) (03/06/89)
In article <9788@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: > Which is yet another error in the implementation of "cake". > /lib/cpp, when it exists, is not intended to be used except via "cc", > and there is no guarantee that /lib/cpp (or "cc -E") will even exist. So why not just remove the call of /lib/cpp from the cake source? Anyway, I recently wrote an "xmake" command that runs its "xmakef" file thru cc -E (which generates a normal makefile) before running the usual make command. I find it convenient for managing multiple versions and targets. -- Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden Tel: +46 (0)758-202 50 Fax: +46 (0)758-197 20 EUnet: rclaeson@ERBE.SE uucp: {uunet,enea}!erbe.se!rclaeson ARPAnet: rclaeson%ERBE.SE@uunet.UU.NET BITNET: rclaeson@ERBE.SE