Registrace nového uživatele     Návod     Kluby     Archív  Lopuchu     Lopuch.cz  

Když diskuse,
tak s Lopuchem

Lopuch.cz

Jméno:
Heslo:
Podpora LCD:
 
Klub C, C++ [ŽP: neomezená] (kategorie Programování) moderuje Šéf Lopuchu.
Archiv

Články

Jak bezpečně ukončit vlákno z DllMain
FastAllocPool - urychlení častých alokací a dealokací
Akce a zpráva jako objekt
Tuply v C++
Efektivní alokátor malých objektů a tady druhý a třetí díl
Šablony: Být vládce kvalifikátorů
Vracíme z funkce objekty
Základy komunikace mezi procesy (ve Windows)
Multiple Interface a Instance Factory
Multithreading v C++ (ve Win32)
  Nastavení klubu     Nastavení práv     Homepage     Anketa     Přítomní     Oblíbené     Lopuch     Kategorie  
autor: 
text: 
vyplnit a 
Help
 Titulek, text příspěvku  
Opište pozpátku následující text bez prostředního znaku: jkaozgi
[ 380 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  
decide 1.3.2007 17:31  601
Express + MFCDRUH 5618 Mohl bys sem hodit odkaz na ten složitý návod na domontování? Dík.
druh_5618 Druh_5618 1.3.2007 13:21  600
JpegCrop [584]MsVC++ 2005 Express Edition neumožňuje v základní instalaci používat MFC. Musí se tam domontovat ručně, je to legální, ale strašně pracné. Nemáte na to někde ten návod???
Naše škola má MsVC++ 2005 Profesional Edition. Smlouva s Microsoftem je postavená tak, že po dobu studia je smí student používat i doma.
Podařilo se mi to zkompilovat, ale v dibtran.cpp to opakovaně hlásilo nedeklarované proměnné i a j. Zřejmě mají být někde deklarovány jako globální, ale nenašel jsem kde, tak jsem je musel připsat do toho souboru jako globální.
mpts mpts Je to jinak, ba přesně naopak! 17.2.2007 21:21  599
Kdokoliv: "Jenze jestli se nepletu, tak kdyz ten vnoreny Makefile volas vzdy, tak nedokazes poznat, jestli ten vnitrni nejakou cinnost provadel, nebo nedelal nic, takze tu cinnost v tom vnejsim (slinkovani) potom musis udelat za vsech okolnosti." -- Dokážeš, jen musíš dát závislost na něco, co ten vnořený Makefile buď změní nebo nezmění, třeba tím touch libsdone.
kdokoliv Kdokoliv Nevidím důvod dělat cokoliv bezdůvodně. - http://kkl2401.wz.cz 17.2.2007 20:18  598
huh [597]: Jenze jestli se nepletu, tak kdyz ten vnoreny Makefile volas vzdy, tak nedokazes poznat, jestli ten vnitrni nejakou cinnost provadel, nebo nedelal nic, takze tu cinnost v tom vnejsim (slinkovani) potom musis udelat za vsech okolnosti. Nebo se mi to aspon nepovedlo obejit.
O antovi vim, zvazuju ho taky, ale zatim se mi do nej nechtelo (ten neznam vubec, Makefily aspon trochu jo, navic make mam po ruce vsude, mravence bych musel doinstalovavat).
huh huh 17.2.2007 16:24  597
Kdokoliv [593]: Ono lze tu zavislost z horniho makefilu jednoduse vyhodit (a IMHO to tak dela vetsina knihoven), takze se vnoreny makefile bude volat vzdy, coz je samo o sobe pomerne nenarocne. Druha moznost je mit ty zavislosti v promenny v samostatnym souboru a z makefilu je jenom includovat a v hornim pak predradit cestu do adresare. Treti moznost je pouzit zastupne znaky pro vygenerovani zavislosti (napr. SOURCES = $(wildcard src/*.java) ). Jinak existuji i lepsi veci nez je make, treba scons nebo konkretne pro javu Ant.
mpts mpts Je to jinak, ba přesně naopak! 16.2.2007 23:32  596
Kdokoliv [593]: To lze obejít, třeba tak, že ten cíl test závisí na test.o a lib/libsdone, přičemž lib/libsdone se udělá v podřízeném Makefile:

all: libtest1.o libtest2.o libtest3.o libtest4.o
	touch libsdone


Takže když v adr. lib přidáš novou knihovnu, stačí změnit soubor Makefile v něm a odstranit libsdone (nejspíš v make clean). Plus ovšem na místě, kde se to linkuje do výsledku, ale i to lze zautomatisovat, nahrubo třeba přes *.o, jemněji přes proměnné aj. Záleží na jen fantasii. :-)
kdokoliv Kdokoliv Nevidím důvod dělat cokoliv bezdůvodně. - http://kkl2401.wz.cz 16.2.2007 23:08  595
Ono to nebude asi az tak hrozny, pokud se nad tim clovek zamysli a ma nejake zkusenosti; mne ty zkusenosti ponekud chybi.
bredy 16.2.2007 22:53  594
Hmm, asi proto používám IDE, která umí vytvářet makefily automaticky. Z tohodle bych se zbláznil.
kdokoliv Kdokoliv Nevidím důvod dělat cokoliv bezdůvodně. - http://kkl2401.wz.cz 16.2.2007 21:53  593
mpts [592]: Jasne, tohle uz je asi to, co jsem chtel (akoratze kdyz jsem to vymyslel pro neco slozitejsiho, tak jsem proste narazil, jenom si uz nepamatuju na co, takze az to zkusim na prakticky priklad, tak se sem urcite vratim s nejakym dalsim problemem). Ja vim, ze to jedno neni pravidlo pro preklad, ale vyjadruje to zavislost toho libtest.o - pokud by to zaviselo na deseti jinych souborech, tak tech deset zavislosti musi byt vyjmenovano na dvou (minimalne na dvou) mistech, kdyz jedna pribude, je potreba tu upravu udelat rovnez na vice mistech.
Jinak mit vsechny obj v adresari obj by bylo hezke, ale problem je v tom, ze ja si tohle vymyslel jako fakt jenom hruby priklad toho, o co se snazim, protoze ve skutecnosti jsou ty zdrojaky javovsky a u tech je ta prace s cestama jeste podstatne divocejsi. :-)
mpts mpts Je to jinak, ba přesně naopak! 16.2.2007 17:51  592
Kdokoliv: No jo, promiň, to slinkování je proto, že ten horní make nevidí ten libtest.o a nemůže se přesvědčit, jestli není nový. Pro tento účel tedy ten horní Makefile bude vypadat:

CC = /bin/cc

CFLAGS = -Wall -g -pipe

all: test

test: test.o lib/libtest.o
	$(CC) $(CFLAGS) -o test test.o lib/libtest.o



test.o: test.c
	$(CC) $(CFLAGS) -c -o test.o test.c



lib/libtest.o: lib/libtest.c
	(cd lib; $(MAKE))



Pak už by to mělo fungovat tak, jak chceš. Jinak také je obvyklé dávat všechny obj soubory potřebné pro závěrečné slinkování do adresáře obj (apod.).

No a s tím počtem, v tom horním Makefile není pravidlo pro překlad, jen odeslání do podadresáře -- vlastní pravidlo bude vždy jen jednou, v Makefile v tom podadresáři. Kolik bude těch horních pseudopravidel, to už záleží na projektu, jak je udělán, jaké tam jsou závislosti atd.
kdokoliv Kdokoliv Nevidím důvod dělat cokoliv bezdůvodně. - http://kkl2401.wz.cz 16.2.2007 14:25  591
mpts [590]: Tak jsem to mel dost podobne. Nicmene nesplnuje to bod (3) - za vsech okolnosti se provadi to finalni slinkovani (tj. i kdyz dvakrat za sebou pustim make), to se mi moc nelibi.
Druha vec, ktera se mi nelibi, je to, ze zavislosti libtest.o jsou popsany na dvou mistech. Coz si navic nejsem jistej, jestli je konecne cislo (tj. nikdy to nebude vic nez dvakrat), protoze v realu se samozrejme bude jednat o projekt vyrazne vetsi (jak do hloubky zanoreni podadresaru, tak do sirky, tedy poctu podadresaru a souboru v nich); pokud by to opravdu bylo maximalne dvakrat, tak by se to asi dalo prezit, pokud by to nejak zaviselo spis na maximalni hloubce zanoreni adresaru (nebo tak necem), tak by to bylo dost nepouzitelny.
mpts mpts Je to jinak, ba přesně naopak! 16.2.2007 12:59  590
KdokolivV hlavním adr. je test.c
#include <stdio.h>

int fce(int co);

int main(void) {
  printf("je to %d\n", fce(2));
  return 0;
}


V podadr. lib je libtest.c
int fce(int co) {
  return 3*co;
}


V hlavním je Makefile:
CC = /bin/cc

CFLAGS = -Wall -g -pipe

all: test

test: test.o libtest.o
	$(CC) $(CFLAGS) -o test test.o lib/libtest.o



test.o: test.c
	$(CC) $(CFLAGS) -c -o test.o test.c



libtest.o: lib/libtest.c
	(cd lib; $(MAKE))



V lib je Makefile:
CC = /bin/cc

CFLAGS = -Wall -g -pipe


all: libtest.o


libtest.o: libtest.c
	$(CC) $(CFLAGS) -c -o libtest.o libtest.c



S header soubory jsem se neobtěžoval. :-)
kdokoliv Kdokoliv Nevidím důvod dělat cokoliv bezdůvodně. - http://kkl2401.wz.cz 16.2.2007 00:42  589
MakefileSorry za lamoidni dotaz, ale bud mi to v tenhle moment uz nemysli nebo nevim. Potreboval bych nakopnout, jak se delaj Makefily pro projekty rozlezeny do vic adresaru (cili cokoliv co ma vic nez par zdrojaku).
Rekneme pro jednoduchost, ze cely projekt se sklada z program.c a jemu odpovidajicimu program.h plus je tam podadresar library obsahujici library.c a library.h.
Cili rucne preklad probiha
cd library
gcc -Wall -c library.c
cd ..
gcc -Wall -c program.c
gcc -Wall -o program library/library.o program.o
A ted ceho bych chtel docilit: budou existovat dva Makefily - jeden v tom hlavnim adresari a jeden v podadresari library. Ten v podadresari library se bude starat o preklad library.c na library.o, ten v hlavnim adresari o preklad program.c na program.o a pak na slinkovani na program. Bude mit ale nasledujici vlastnosti (ve chvili, kdy jsem v hlavnim adresari a napisu make).
(1) Pokud se zmeni program.h nebo program.c, provede se kompilace program.c a slinkovani (ale neprovede se kompilace library/library.c).
(2) Pokud se zmeni library/library.h nebo library/library.c, provede se kompilace library/library.c a slinkovani (ale neprovede se kompilace program.c).
(3) Pokud se nezmeni ani jeden z hlavickovych nebo zdrojovych souboru, neprovede se vubec nic.
Moje otazka zni - daji se vubec cile v tech Makefilech napsat tak, aby to tohle splnovalo? Jak?
bredy 2.2.2007 20:04  588
JIT Debugging v linuxu? Docela chybí, pokud člověk ladí třeba forkované procesy. Ale dá se to
huh huh 25.1.2007 13:55  587
DRUH 5618 [586]: MSVC 6 plna + posledni SP
jakej workspace oteviras?

[ 380 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  

(c) 2001-2011 Lopuch.cz   
Kontakt