Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | |
[VC++ Linker] Так ты и будешь это делать одним действием 11.12.03 12:00 Число просмотров: 1890
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
> Тут дело в том, что хочется именно всего одним макросом это
> переключать
> тоесть одним действием, чтобы не лазать там, сям
Ты будешь только переключать активню конфигурацию. Делаешь, чтобы в одной конфигурации этот макрос был предопределен, а в другой нет, и все. Хотя честно говоря, идея amirul'а мне импонирует куда больше - как-то я забыл, что в Visual C++ тоже мейкфайлы есть.
|
|
<programming>
|
[VC++ Linker] Как макросами поменять имя EXE файла ны выходе? 11.12.03 02:45
Автор: Disappear Статус: Незарегистрированный пользователь
|
Такая ситуация: нужно чтобы макрос переключал имя EXE файла при компиляции программы, тоесть например - если макрос defined то имя файла было file1.exe иначе file2.exe
пробовал: #pragma comment(linker, "/OUT:file1.exe") - не получилось, впринципе и в МСДН сказано что так делать нельзя
может есть еще какие хитрые способы?
|
|
[VC++ Linker] Makefile? 11.12.03 03:27
Автор: amirul <Serge> Статус: The Elderman
|
> может есть еще какие хитрые способы?
Если нужно делать что то чересчур хитрое, то без Makefile-а обычно не обойтись.
Чтобы иметь IDE и одну конфигурацию, но иметь возможность собирать разные exe-шники можно поиграться с "Custom Build" или "Post Build" закладками и там переименовывать слинкованный файл.
|
| |
[VC++ Linker] Post Build? 11.12.03 15:41
Автор: Disappear Статус: Незарегистрированный пользователь
|
|
А как можно в Post Build отловить включен макрос в коде или нет?
|
| | |
[VC++ Linker] Общий ответ: никак 11.12.03 15:49
Автор: amirul <Serge> Статус: The Elderman
|
> А как можно в Post Build отловить включен макрос в коде или
> нет?
Немного более развернутый: можно этот макрос вынести в отдельный файл (для более простого парсинга), а какой нибудь внешней утилитой выкусывать оттуда его значение (awk вполне справится или собственного написания).
Но мне, как и Ktirf-у больше нравится идея с Makefile-ом :-)
|
| | | |
[VC++ Linker] Makefile круто... 11.12.03 16:12
Автор: Disappear Статус: Незарегистрированный пользователь
|
> > А как можно в Post Build отловить включен макрос в
> коде или
> > нет?
> Немного более развернутый: можно этот макрос вынести в
> отдельный файл (для более простого парсинга), а какой
> нибудь внешней утилитой выкусывать оттуда его значение (awk
> вполне справится или собственного написания).
>
> Но мне, как и Ktirf-у больше нравится идея с Makefile-ом
> :-)
Проблема в том что я ничего в формате makefile не соображаю, но как я подозреваю, для переключений EXE придется уже менять не макрос а строчку в makefile?
|
| | | | |
[VC++ Linker] Ага 11.12.03 17:05
Автор: amirul <Serge> Статус: The Elderman
Отредактировано 11.12.03 17:07 Количество правок: 2
|
> Проблема в том что я ничего в формате makefile не
> соображаю, но как я подозреваю, для переключений EXE
> придется уже менять не макрос а строчку в makefile?
Да, там есть свои переменные и условная компиляция. Лушче всего сделать название результирующего файла сделать переменной.
Синтаксис очень подробно описан в MSDN. Лучше взять готовый (VC6 умеет экспортировать проекты в makefile-ы, в VC.Net я этого не нашел) и подредактировать немного. Там все понятно в принципе
Синтаксис:
цель: цели-зависимости
команда1
команда2
.... и так далее
---
Цель - это как подпрограмма в языке программирования. Целью может быть как файл так и произвольное название (почти произвольное). Если у собираемой цели есть цели-зависимости, то сначала собираются они (рекурсивно). А сам процесс сборки цели описывается командами. Команды обязательно должны иметь отступ. Если его нет - то это уже новая цель.
Когда делаешь
nmake -f Makefile
то бишь не указываешь цель явно, то собирается цель all
Замечу, что при такой сборке лучше в VC.Net при создании проекта явно указывать "Makefile Project". Тогда проект можно будет все так же собирать из IDE, но собираться он будет внешней командой (в данном случае nmake).
Короче выглядеть это будет примерно так
Строчку
ALL : "$(OUTDIR)\test.exe"
---
заменяем на
CONFIG=1
!if "$(CONFIG)"=="1"
TARGET=$(OUTDIR)\test1.exe
!else
TARGET=$(OUTDIR)\test2.exe
!endif
ALL: "$(TARGET)"
---
Остальное оставь без изменений. Можешь включить этот Makefile в свой проект и менять номер конфигурации прямо там. Это не труднее, чем переопределение макроса. Также можно вызывать это следующим образом:
nmake -f Makefile CONFIG=2
В общем, для начала сведений достаточно. Дальше MSDN в зубы и вперед на мины :-) Там на самом деле не все так сложно как кажется сначала.
ЗЫ: Вот нашлась и вторая причина по которой я не хочу пересаживаться на VC.Net - не умеет экспортировать Makefile-ы. Первая была, что он не умеет импортировать ключи для компилятора прямо в проект. То есть умеет, но он не строит на их основе новые настройки для проекта, а просто принимает и ничего с ними не делает и в то же время не дает ничего сделать с уже сгенеренными (как в VC6)
|
| | | | | |
[VC++ Linker] Пасибо! 11.12.03 22:56
Автор: Disappear Статус: Незарегистрированный пользователь
|
> > Проблема в том что я ничего в формате makefile не
> > соображаю, но как я подозреваю, для переключений EXE
> > придется уже менять не макрос а строчку в makefile?
> Да, там есть свои переменные и условная компиляция. Лушче
> всего сделать название результирующего файла сделать
> переменной.
>
> Синтаксис очень подробно описан в MSDN. Лучше взять готовый
> (VC6 умеет экспортировать проекты в makefile-ы, в VC.Net я
> этого не нашел) и подредактировать немного. Там все понятно
> в принципе
>
> Синтаксис:
> > цель: цели-зависимости
> команда1
> команда2
> .... и так далее
>
---
> Цель - это как подпрограмма в языке программирования. Целью
> может быть как файл так и произвольное название (почти
> произвольное). Если у собираемой цели есть
> цели-зависимости, то сначала собираются они (рекурсивно). А
> сам процесс сборки цели описывается командами. Команды
> обязательно должны иметь отступ. Если его нет - то это уже
> новая цель.
>
> Когда делаешь
> nmake -f Makefile
> то бишь не указываешь цель явно, то собирается цель all
>
> Замечу, что при такой сборке лучше в VC.Net при создании
> проекта явно указывать "Makefile Project". Тогда проект
> можно будет все так же собирать из IDE, но собираться он
> будет внешней командой (в данном случае nmake).
>
> Короче выглядеть это будет примерно так
>
> Строчку
> > ALL : "$(OUTDIR)\test.exe"
>
---
>
> заменяем на
> > CONFIG=1
> !if "$(CONFIG)"=="1"
> TARGET=$(OUTDIR)\test1.exe
> !else
> TARGET=$(OUTDIR)\test2.exe
> !endif
>
> ALL: "$(TARGET)"
>
---
>
> Остальное оставь без изменений. Можешь включить этот
> Makefile в свой проект и менять номер конфигурации прямо
> там. Это не труднее, чем переопределение макроса. Также
> можно вызывать это следующим образом:
>
> nmake -f Makefile CONFIG=2
>
> В общем, для начала сведений достаточно. Дальше MSDN в зубы
> и вперед на мины :-) Там на самом деле не все так сложно
> как кажется сначала.
>
> ЗЫ: Вот нашлась и вторая причина по которой я не хочу
> пересаживаться на VC.Net - не умеет экспортировать
> Makefile-ы. Первая была, что он не умеет импортировать
> ключи для компилятора прямо в проект. То есть умеет, но он
> не строит на их основе новые настройки для проекта, а
> просто принимает и ничего с ними не делает и в то же время
> не дает ничего сделать с уже сгенеренными (как в VC6)
А мне кажется на VS .NET лично сишникам не стоит переходить ближайшие год-два. VS .NET вроде как заточен на .NET и C#, поэтому микрософт задачу полной совместимоти c VS6 на первый план не будет ставить.
|
|
[VC++ Linker] Боюсь, что ничего лучшего, чем две отдельных конфигурации сборки, посоветовать не могу. 11.12.03 02:50
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
|
Правда, это дублирование :(
|
| |
[VC++ Linker] А как я их буду переключать 11.12.03 03:31
Автор: Disappear Статус: Незарегистрированный пользователь
|
Тут дело в том, что хочется именно всего одним макросом это переключать
тоесть одним действием, чтобы не лазать там, сям
|
| | |
[VC++ Linker] Так ты и будешь это делать одним действием 11.12.03 12:00
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
> Тут дело в том, что хочется именно всего одним макросом это
> переключать
> тоесть одним действием, чтобы не лазать там, сям
Ты будешь только переключать активню конфигурацию. Делаешь, чтобы в одной конфигурации этот макрос был предопределен, а в другой нет, и все. Хотя честно говоря, идея amirul'а мне импонирует куда больше - как-то я забыл, что в Visual C++ тоже мейкфайлы есть.
|
| | | |
[VC++ Linker] Ага. В VC.Net текущая активная конфигурация вынесена на тулбар 11.12.03 15:54
Автор: amirul <Serge> Статус: The Elderman
|
> > Тут дело в том, что хочется именно всего одним
> макросом это
> > переключать
> > тоесть одним действием, чтобы не лазать там, сям
> Ты будешь только переключать активню конфигурацию. Делаешь,
> чтобы в одной конфигурации этот макрос был предопределен, а
Так что действий будет еще меньше, чем редактирование текста (определение/убирание макроса). Единственная проблема, которая может возникнуть: рассинхронизация этих конфигураций. То бишь, ты можешь в одну из них внести какие то дополнительные настройки, а в другую забыть. Хотя, честно говоря не такая уж это и проблема, если вспомнить как редко обычно меняются настройки.
Так что советую выбирать или этот вариант или немного более сложный в реализации (для новичка), но гораздо более гибкий вариант с Makefile-ом. Вариант с Post-Build-ом я предложил просто для того, чтобы осветить все возможности, но мне честно говоря он кажется самым плохим: и сложный и не гибкий.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
