bnmurphy / PMCAMx-2008

This Repository is for testing version control between SU, Patras, and CMU
Other
3 stars 1 forks source link

netbeans build target is currently configured for windows #16

Open sebarn opened 10 years ago

sebarn commented 10 years ago

did some serious cleaning up in the makefile in netbeans. configured a build target. also used -Bstatic flag in iFort which makes linking a lot faster (and this is how it's supposed to be done for libraries that are user generated).

this is our problem for the executable that is built: (this is the first line of the output of the compiler on triolith)

make model FC="ifort" FLGS="-I./Inc -fpe3 -traceback -align dcommons -extend_source -convert big_endian -mcmodel=medium -Bstatic" TARGT="PMCAMx.exe" DUM=dummy

currently the target is set to a Windows architecture, i.e. the target is an .exe. this will not run on a linux machine. work in progress ;-).

sebarn commented 10 years ago

I think the reason for this is that this project is missing a target.mk file (see link below). Should not be hard to fix. But I'll play around with this for my HPC project.

make multi-architecture

bnmurphy commented 10 years ago

I'm not convinced that the executable is built for a windows architecture, just because it is named with a ,exe extension. I know Windows makes assumptions about files based on the extension name. But, it's not clear to me that linux does this as fool-heartily. If there were an option in the compile statement that explicitly set the output architecture to Windows, that would be a different story.

I'm not sure about the target.mk idea. I agree that there's something about netbeans that I'm just not getting, but I wonder if its more subtle than file execution problems. Something like the difference between project spaces and the decision-tree behind build operations, etc.

sebarn commented 10 years ago

I don't think it's more subtle than that. Whenever I configure a NetBeans project from scratch, the *.tk file is included. Currently there is no such file, so NetBeans just uses the remote host ( triolith) for building a windows OS executable.

sebarn commented 10 years ago

if I run the file command on CAMx4.chemparam.5.Base, I get this output:

image

equally for CAMx.ladco.linux, I get this: image

So I have no clue what CRLF line terminators are and I have no clue what the output for CAMx.ladco.linux means, but I think this could be related to the issue.

sebarn commented 10 years ago

some more output from a google search

Building Software for Multiple Platforms

bnmurphy commented 10 years ago

Tried a couple of different workarounds today The following have been successful:

-With source code stored on Triolith, Netbeans can edit, build and run it fine. All shell scripts are read correctly. Netbeans can NOT access any git functionality, even with the repository created manually on Triolith.

-With source code stored locally (Windows 7) Netbeans has full git functionality, can remote build and remote run, but occasionally (not always) shell script and text files become encoded wrong. The executable is fine though. Submitting jobs to the queue must be done through the terminal window.

One annoyance with this second setup: any scripts that are changed are updated only during "clean and build" or can be manually moved over to Triolith. It would be nice if saving them updated them automatically.

The DDT debugger, available on Triolith, has been successfully applied to debug PMCAMx-2008. This is a big gain for PMCAMx development which, to my knowledge, has never had the benefit of a graphical debugger.

This setup is still at the stage that only a proficient user can navigate it, in my opinion. We need to figure out how to streamline this whole setup, especially with regard to the code structure. In other words, can it be restructured to work WITH netbeans instead of against it so often?

sebarn commented 10 years ago

what exactly do you mean by

Netbeans can NOT access any git functionality

?

awesome work by the way