Developer Forum

Hello,

we are building a mixed Linux/Windows application, which includes
drivers. We use the build.exe tool for Windows, and GNU Make for Linux.


Now, the directory structure is as follows:

<project>\Makefile - GNU Makefile
<project>\dirs - dirs file for build.exe; contains WINBUILD
<project>\source.c - source file
<project>\WINBUILD\Makefile - Makefile for build.exe
<project>\WINBUILD\sources - sources file for build.exe; contains
..\source.c

This worked perfectly for XP DDKs and 2K3 DDK. Unfortunately, as I just
tried with 2K3 SP1 RC 1 DDK, I found an annoying change in the
behaviour:

While previous build.exe ignored a Makefile which is present in the same
directory as a 'dirs' file, this is not true anymore with the build.exe
from 2K3 SP1 DDK. Thus, if I compile the above structure, nmake
complains about definitions it does not recognize (because these are
intended for GNU Make, with its different syntax).

This is annoying. :-(

I believe I once read somewhere in the DDK documentation the Makefile is
only searched for in directories where a sources file resides, but I
cannot find that comment anymore.

Is the behaviour changed deliberately? Is it a bug? Am I doing something
wrong?

Any suggestions on what I can do to resolve this issue? Currently, I'm
deleting all GNU Makefiles before compiling, but this is no long-term
solution.

Regards,
Spiro.

--
Spiro R. Trikaliotis
http://www.yqcomputer.com/

Get rid of the dir file and modify the gnu makefile to have gnu make recurse
into the NT build directory then invoke setenv.bat/build.exe

Calvin
--
Calvin Guan Software Engineer/Radeon NT Drivers
ATI Technologies Inc. Markham ON, Canada www.ati.com

Hallo Calvin,




Yes, at first hand, this sounds as a good idea. Unfortunately, the
sources should build even on computers where no GNU Make is available,
only using the DDK. This would not work with your proposal.

Are there any other hints/ideas?

Regards,
Spiro.

--
Spiro R. Trikaliotis
http://www.yqcomputer.com/

Hello,




I just set up a small example for what I mean:

http://www.yqcomputer.com/

This compiles on XP and 2003 DDK, but not on 2003 SP1 RC1 DDK.

(the Makefile is not totally ignored, but nmake only issues a warning
for older DDKs. For newer ones, there is an error.)

Does anybody know how I can set up a Makefile which is only recognized
by GNU Make, but not by nmake? For example, some conditional expression
BOTH makes recognize?

Regards,
Spiro.

--
Spiro R. Trikaliotis
http://www.yqcomputer.com/

Hi Spiro,

I have had such kind of problem myself, and I found a solution!

The trick is to name the makefile that only gnu make needs to process
'gnumakefile'. The build.exe and all other make programs will not recognize
this file as beeing a makefile, while gnu make will recognize and start
'executing' it.

I hope this will solve your problems too. I did download your zip file and
renamed the makefile and now it builds without warnings with build.exe -cZ.
Also it works with gnu make (produces an error due to the content of the
gnumakefile file.
I did not try it with the latest DDK, simply because I don't have it
installed (yet) but I don't expect problems there.

Good luck, Jeroen.

Hello Jeroen,

thanks for your answer.




*sigh* Yes, unfortunately, I already know this. Unfortunately, GNU Make
tells that the name "GNUMakefile" should only be used if the makefile
uses GNU extensions. In this case, this is not the case.

Well, I would not have any problems using GNUMakefile nevertheless, but
there are other people having ideological problems with this. Thus, I
hoped to find another solution.

You know, in the beginning, this project was Unix only. It has been
ported to Windows afterwards. Thus, the Unix people feel that Windows
should adapt to them. :-(



No, no problem at all. This was tested long ago, and I know for sure
that it works.

My newest proposal was to move the GNU Makefile "out of the way" and use
symbolic links in a special prepare-script before compiling. I hope this
will be accepted, but I have doubts.



Thank you very much!

Regards,
Spiro.

--
Spiro R. Trikaliotis
http://www.yqcomputer.com/

Write your own BUILD for UNIX (using, say, PHP or even shell script).
It will parse DIRS itself and invoke makefiles in the subdirs.
After this, get rid of the Makefile in the same directory as DIRS.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
XXXX@XXXXX.COM
http://www.yqcomputer.com/

Hello Maxim,




Well... yes, I remember you already told me so. Anyway, as there are
some subtle differences in the build systems between Linux and Windows,
I would like to find an easier solution.

It seems I found some which can be accepted by both parties:

In every directory A, there is the following layout:

- A
- A/<somefiles> - files which are common to Windows and Linux
- A/dirs - for build.exe
- A/WINDOWS/Makefile - makefile specific to Windows
- A/LINUX/Makefile - makefile specific to Linux


... as I told before. The only difference: The GNU makefile is moved
from A/Makefile to A/LINUX/Makefile. Now, make is called with the option
-f LINUX/Makefile, and everything works fine.

Thank you and Jeroen for your help!

Regards,
Spiro.

--
Spiro R. Trikaliotis
http://www.yqcomputer.com/

Or even easier:
- make the WINDOWS subdirectory
- put MAKEFILE/SOURCES there. SOURCES will include SOURCES.INC
- put SOURCES.INC in the main directory

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
XXXX@XXXXX.COM
http://www.yqcomputer.com/

Hello Maxim,




I fail to see why putting sources.inc in the main directory makes this
easier. Could you please tell me what you meant?

Regards,
Spiro.

--
Spiro R. Trikaliotis
http://www.yqcomputer.com/

> I fail to see why putting sources.inc in the main directory makes this

The makefile used by Windows will be in $\Windows subdir, and the makefile in
the main dir will be Linux-only.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
XXXX@XXXXX.COM
http://www.yqcomputer.com/

Hello Maxim,




But: That is exactly what does not work.

I always thought that a Makefile ("in the main dir") will not be
executed if there is no sources files. This is not true. While we get an
error but build.exe does not abort in 3790, build.exe aborts in
3790.1289. That was the starting point why I started this thread. ;-)

Regards,
Spiro.

--
Spiro R. Trikaliotis
http://www.yqcomputer.com/