C, C++ - diskusní klub na Lopuchu

Registrace nového uživatele

Návod

Kluby

Archív Lopuchu

Lopuch.cz

Komu se nelení,
tomu se zelení.

Lopuch.cz

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

Help

[ 380 ]

<Novější <<<Nejnovější Nejstarší>>> Starší>


	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 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.


	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 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 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 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 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 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?


	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 25.1.2007 13:55	587
	DRUH 5618 [586]: MSVC 6 plna + posledni SP jakej workspace oteviras?


	Druh_5618 25.1.2007 11:15	586
	Já vím, ale chtěl jsem si v něm pár věci upravit k obrazu svému. V jaké verzi Studia jsi to zkompiloval? Jakou máš verzi MFC ???


	huh 23.1.2007 15:19	585
	DRUH 5618 [584]: Vzdyt tam uz skompilovany je. Jinak me to jde zkompilovat bez problemu.


	Druh_5618 23.1.2007 12:39	584
	Prosba Pokusil by se, prosím, někdo z vás z těchle zdrojáků zkompilovat JpegCrop ??? jcropsrc.zip MsVC 6.0 Introductory Edititon mi neustále vyhazuje LNK2005.


	20.11.2006 00:02	583
	Linux - signaly s UI (QT a GTK?)V rámci přepisování multithreadové knihovny do Linuxu jsem narazil na malý problém, jedná se mi o čekací funkce v UI. Základem čekací funkce v UI je zvláštní chování, kdy vlakno čeká na nějaký zámek, ale při tom sleduje aktivitu uživatele, takže může během čekání reagovat na nějakou akci uživatele (přesun okna, kliknutí na tlačítko Storno, a jiné). To vše kvůli Windowsům a jejich message-loop. A teď otázka, je toto nějak možné postihnout v QT / GTK? hledám obecné řešení, abych si na to mohl připravit interface. Jinými slovy, mám možnost testovat (periodicky, nebo signálem, nebo jinak se dozvědět), že uživatel něco udělal, a přeje si být obsloužen? Má někdo s tímto zkušenosti?


	mpts Je to jinak, ba přesně naopak! 19.11.2006 20:18	582
	Není-li to ovšem dotaz typu: "Kdo mi napíše zápočtový program?" :-))

[ 380 ]

<Novější <<<Nejnovější Nejstarší>>> Starší>


(c) 2001-2011 Lopuch.cz Kontakt