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

Něco navíc v zeleném?
A proč ne...

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: fhofrwy
[ 380 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  
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?
druh_5618 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 huh 23.1.2007 15:19  585
DRUH 5618 [584]: Vzdyt tam uz skompilovany je. Jinak me to jde zkompilovat bez problemu.
druh_5618 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.
bredy 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 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