Build és #define makrók

Clipper, CCC

Már előjött néhányszor, hogy kényelmetlenséget okoz néha, hogy a build-nek nem lehet parancssorból makrókat megadni, a C++-ban megszokott -D-hez hasonlóan. Például az SQL2-ben is külön könyvtárak kellenek connect-pg és connect-ora néven ahhoz, hogy elfedjék a DBMS réteget. Szerintem kéne csinálni egy -t paramétert a buildnek, ami nézhetne ki úgy, hogy -t DEBUG egyenértékű egy #define DEBUG-gal, és ha fullextrát akarunk, akkor meg lehetne olyat is, hogy -t VALAMI "kifejezés", ami pedig egy #define VALAMI kifejezés sorral lenne egyenértékű. Vélemény?

w

( mrev | 2007. 01. 29., h – 14:35 )

Meg lehet élni -D nélkül, pl.:

1) A winhez való define-okat tartalmazó include-okat egy windows subdirectoryba teszed a unixososkat egy unixba. A build paramfilébe beírod, hogy -iwindows vagy -iunix.

2) Csinálsz egy debug.ch filét, beleírod #define DEBUG. Ha mégsem akarsz debugolni kikommentezed. Ha mégis, akkor visszarakod.

3) Tfh, volna egy nagyon hasznos programod, ami megoldaná az afrikai éhínség problémáját, de csak úgy tudod lefordítani, ha megadod neki: -DAFRIKA. Akkor beállíthatod a BUILD_PRE változót, ennek az értékét a build továbbadja a preprocesszornak (prg2ppo), pl:

bapp_unix_.b BUILD_PRE=-DAFRIKA

vagy

bapp_unixc.b BUILD_PRE='-DXX="xxx" -DYY="yyy" -DZZ="zzz"'

Ezzel az utolsó módszerrel nehézségek vannak: A parancssor platformfüggő. A wines parancssor hossza korlátozott. A build a paramfiléből nem tud felszedni bonyolultabb definíciókat, mert a paramfiléket sorvégeknél és szóközönél vagdalja. Emiatt nem akarok ebbe az irányba menni

--
CCC3

( vadzoltan | 2007. 02. 19., h – 16:12 )

Hi,

Lenne egy a preprocesszor működésével kapcsolatos kérdésem.
Az 1. pontban látható CCC forrás preprocesszálása után 


#!/bin/bash
prg2ppo.exe  proba2.prg -oproba2.ppo @prg2ppo.opt -i/$CCCDIR/usr/include

a 2. pontban látható eredmény kapjuk. A probléma a line 22 ben található extra space. 


c := {|x1,x2,x3|a (x1,x2,x3)} 
                 ^ 
                extra space

Lehetséges ennek a kivédése ?

Előre is köszönettel
Vad Zoltán

1. proba.prg
----------------- 



#xtranslate ARGLISTA(<list,...>) => <list>

(ARGLISTA(l1,l2,l3))


#define FCALL(f,arglist) { |arglist|  f##(arglist) }
#define MCALL(f)         FCALL(f,ARGLISTA(x1,x2,x3))


FCALL(a,b)

FCALL(a,ARGLISTA(x1,x2,x3))
MCALL(x)




#translate MTOGGLE <f>  TO <b> => <b> := MCALL(<f>)
MTOGGLE a  TO c

>------------- eof proba



~
~
2. PPO result


#line 6 "proba2.prg"
(l1,l2,l3)
#line 13 "proba2.prg"
{|b|a(b)}
#line 15 "proba2.prg"
{|x1,x2,x3|a(x1,x2,x3)}
{|x1,x2,x3|x(x1,x2,x3)}
#line 22 "proba2.prg"
c := {|x1,x2,x3|a (x1,x2,x3)}
#line 26 "proba2.prg"
~
~

Mielőtt kiröhögtök, gyorsan meg is válaszolom magamnak, hogy ez valószínüleg nem probléma. Csak miután elküldtem a szöveget jutott eszembe az
ellenőrzés, mert csak ppo-t néztem.
az fgv (a,b) teljesen jol fordul es nem okoz problémát. Bocsánat. A történet csak az , hogy régi forrásaimat raktam át ccc-re, és bizonyos szofisztikált translate parancsokra nem ugy működött (természetesen) a ccc preprocesszora mint a Clippere. Az adaptáció közben csak ppo-t néztem
egy külön letisztitott környezetben. Mégegyszer tekintsétek semmisnek a kérdést.

Köszi
Vad Zoltán

Van egy alternatív preprocesszor, a cccpp (Cs.L.), ami jobban hasonlít a régi Clipper preprocesszorhoz. A cccpp egy tízezer soros C program szemben a prg2ppo-val, ami Flex/Lemon/CCC modulokból áll.

Amit itt csinálsz a preprocesszorral, azt könnyebben el lehet érni a vararg API-val.

Az eredeti Clipper preprocesszor egyébként hihetetlenül bonyolult jószág, és nem is sikerült utólérni. Pl. a translate szabályok jobb oldalára lehet írni újabb szabályokat. Ilyet a prg2ppo nem tud. A cccpp-ről nem tudom, hogy tudja-e.

--
CCC3

Köszönöm, a vararg api-ról tudok, és nagyon örülök neki, bizonyosan használni is fogom. A jelen esetben csak arról van szó , hogy egy meglehetősen
nagy méretű clipper forrásból portolok CCC alá modulokat és mivel szoros határidők kötnek, gyorsan kell eredményt elérnem. Igy a legeygszerűbbnek az tűnt, hogy a commandokat igazítom a CCC-re. Ez már rendben is van. Most egy menu renszerről van szó, amelyben parancsok segiségével adhatsz hozza
pl toggle tipusú promptokat a menühöz. Itt megadhatsz egy speciális szigantúrájú függvénynevet, amely a toggle billegetésekor, vagy a submenu -be
való belépéskor lefut. Csak a függvénynevet kell megadnod és a parancs legyártja a kódblokkot, amely a spéci paraméterlistával hívja a callback függvényt. Tegnap este befejeztem a modul portolását, minden ok.
Igazából hosszú távon ez nem jó gyakorlat amit csinálok, mert az akkori kódokra nagyon rányomta a bélyegét a clipper által nyújtott szűkös lehtőség.
Nagyon sok struktúrát egymásba ágyazott tömbként realizáltunk, és hogy a kód olvashatóságát megtartsuk, #define -al hivatkoztunk az indexekre.
Most az OOP és namespace-ek felhasználásával, továbbá azzal, hogy teljesen szabad a pálya a C++ részek integrálásával, nyilván a régi kódokat át kell
írni az új környezetre, amint erre kapacitásban lehetőség lesz. Én személy szerint nagy reményeket fűzök a CCC-hez, mert egy olyan környezetet látok magam előtt, amelyet teljesen a kezemben tudok tartani, és ami a lényeg nem kell kilépnem belőle. Az természetes hogy erőfeszítéseket kell tenni abban az irányban, hogy olvasni kell tudni a C résszeket, ismerni kell a veremgép primitivjeit. De szerintem ez visszajön. A CCC-t én egy általános keretrendszernek tekinem, ahol dönthetek, hogy lazán összeragasztom a C-ben általam írt, vagy már meglévő forrásokat, vagy esetleg C-ben folytatom.
Az pedig, hogy még flex/lemon is integrált, csak zene a fülemnek ( most írtam -írok egy Hl7 parsert - egészségügyi rendszerek kommunikációs protokollja).
Köszi:VadZ.